Howdy Gabriel,
That's a pretty awesome guide. I dare say you've sold me on the ECC
memory (once I can find it in suppliers around AU) but it's a shame I'm
limited in the space I've got and need to stick with the mini-itx form
factor and for the life of me don't think a motherboard supports ECC
with LGA1155 in the mini-itx form factor. Please feel free to prove me
wrong though.
On 9/03/2011 7:38 PM, Gabriel de la Cruz wrote:
Hi, with ZFS you dont need a raid card, ZFS will handle the drives on
its own. However, if you are mirroring, the performance improves if
both drives are on different controllers. Any controller supported by
OI will do well for that purpose. I guess any PCI-E will do the job. A
setup could be like this:
Sata port 1 on the controller 1 and Sata port 1 on the controller 2
will be a mirrored pool used for the system "rpool: c1d0s0-c2d0s0".
The rest of the ports could make another pool for the data, either
using another type of raid configurations, or keeping the mirroring
concept; a single data pool made by 3 mirrors (DATApool:
c1d1s0-c2d1s0, c1d2s0-c2d2s0, c1d3s0-c2d3s0).
You should always make a memory test after purchasing memory, this
will point out any hardware defects in the memory or you could even
point out underlying problems with the motherboard. The same goes with
hardrives, you should always take a look at SMART output messages and
make sure if the drives are storing the data at the speed they are
suppose to store the data. That way you can bring the faulty stuff
back to the store before it is too late.
Lets consider this situation: You are writing a file to a mirrored ZFS
pool, the data is stored on both sides of the pool A and B. The drive
A was faulty so it corrupted some bits. But next time you retrieve the
data, ZFS is smart enough to know that A was corrupted so it reads the
info from B and fixes A with the correct data. (Maybe drive A was not
broken, but your faulty PSU was doing tricks.. but it was fixed)
Super. But, lets imagine that you are storing another file, this time
the memory does something funny (it doesn't need to be a faulty memory
in order to do something funny, it could be produced by the
motherboard as well) and some corrupted bits are written in both sides
of the pool. Those bits will never be corrected. I dont think it will
make any difference to back up the corrupted bits to CD once a week.
Anyway, this is not as critical as it might sound, they are just a few
bits, it all depends in what is the probability of corrupting those
bits you really need :P The probability could be extremely small
depending what kind of data you are handling.
The point of failure would be the time when the bits are written to
disk. You will anyway have ZFS snapshots, to roll back to earlier
versions, and so on.
If you are not running the system 24/7, maybe you can make a memory
check from time to time, memory wont go wrong so easily over time but
who knows, I have seen how some broken capacitors were affecting a
memory check! (once upon a time, at the university we had to fix by
hand about 30 DELL office workstations, once we replaced the
capacitors memchecks came clean again!... low budget life! :D ).
I personally dislike CDs, no phisical copy will last forever, and the
ability of replicating the data is more powerful, specially when you
can monitor hardrive failures as ZFS does. But thats a different story
with no ECC (In that case replication could be a point of failure).
There are many backup options out there, it all depends how
complicated do you want your life to be; running amanda on a separate
backup pool? e-sata drives as backup tape? You can allways keep an
external drive unplugged in your wardrobe...
Anyway, taking risks is very necessary in order to move on, otherwise
we would never go anywhere!.
Remember that ZFS has amazing compression capabilities, consider ZFS
in the backup media as well. And remember compressing the data uses
processing power but it stores faster on the hardrive (less data to
write), so if you are dedicating an processor just to the storage
machine, remember to compress :D
Cheers!
On Wed, Mar 9, 2011 at 8:43 AM, Scott O'Brien<[email protected]> wrote:
Wow thanks for all the replies. The DH67CF looks perfect. A few more
silly questions though, if I do a memory test before installing am I
right to use this considering it's non-ecc? I'd still be backing my
important data up to cd once a month. Second question is about
installing, is it considered bad practice to install the os on the
same raid pool as your data? If so is there any pci-e sata
controllers anyone can recommend?
Thanks once again,
Scott o
On 08/03/2011, at 11:42 PM, ken mays<[email protected]> wrote:
Hi Scott& Deano,
You can use the Intel DH67CF motherboard. Everything is detected and works well
for file server usage.
~ Ken Mays
--- On Tue, 3/8/11, Deano<[email protected]> wrote:
From: Deano<[email protected]>
Subject: Re: [OpenIndiana-discuss] Building a machine
To: "'Discussion list for OpenIndiana'"<[email protected]>
Date: Tuesday, March 8, 2011, 6:31 AM
Hi Scott,
There is a HCL at http://wiki.openindiana.org/oi/Community+HCL that
might
have some suggestions, though don't think there are
any/many mini-itx boards
on there.
Most boards seems to work well with OpenIndiana, especially
if on Intel
chipsets.
Bye,
Deano
-----Original Message-----
From: Scott O'Brien [mailto:[email protected]]
Sent: 08 March 2011 10:26
To: [email protected]
Subject: [OpenIndiana-discuss] Building a machine
G'Day Everyone,
First post on the mailing list. I've just got a few
quick questions.
I've found a case I want to build a file server with (just
for home)
http://www.pccasegear.com/index.php?main_page=product_info&cPath=25_1055&pro
ducts_id=14503
<http://www.pccasegear.com/index.php?main_page=product_info&cPath=25_1055&pr
oducts_id=14503>
now I'm at a loss as to what mini-itx motherboard I should
put in it. I
was kind of hoping for one of the new low power Sandy
Bridge CPU's but
can't find any on pccasegear.com. Any advice on
motherboard and HD's to
get? Any idea about how to tell with OpenIndiana
compatibility?
Thanks,
Scott
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
