[OpenIndiana-discuss] Building a machine

Gabriel de la Cruz gabriel.delacruz at gmail.com
Wed Mar 9 08:38:10 UTC 2011

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


On Wed, Mar 9, 2011 at 8:43 AM, Scott O'Brien <king.scott.2 at gmail.com> 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 <maybird1776 at yahoo.com> 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 <deano at rattie.demon.co.uk> wrote:
>>> From: Deano <deano at rattie.demon.co.uk>
>>> Subject: Re: [OpenIndiana-discuss] Building a machine
>>> To: "'Discussion list for OpenIndiana'" <openindiana-discuss at openindiana.org>
>>> 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:king.scott.2 at gmail.com]
>>> Sent: 08 March 2011 10:26
>>> To: openindiana-discuss at openindiana.org
>>> 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
>>> OpenIndiana-discuss at openindiana.org
>>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>> _______________________________________________
>>> OpenIndiana-discuss mailing list
>>> OpenIndiana-discuss at openindiana.org
>>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>> _______________________________________________
>> OpenIndiana-discuss mailing list
>> OpenIndiana-discuss at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss

More information about the OpenIndiana-discuss mailing list