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
