From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <7d3530220906241043n2a6e153ao259d4b4082c7020f@mail.gmail.com> <7d3530220906241633i1fdb3c27q7d389d998ef02e96@mail.gmail.com> From: Venkatesh Srinivas Date: Wed, 24 Jun 2009 20:00:08 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] fossil/venti falling down? Topicbox-Message-UUID: 0ed33d8a-ead5-11e9-9d60-3106f5b1d025 On Wed, Jun 24, 2009 at 7:39 PM, erik quanstrom wrote: >> So I went ahead and reinstalled fossil and venti--this time I went >> with a RAID-10 configuration on the Coraid. > > for data integrety, raid 5 is a better solution because > on a raid 10, if one block is wrong, it's a coin flip as > to which one is correct (if any). with raid 5, it's possible > to determine which disk has the incorrect information. > Not directly related to the topic here, but this has always bugged me about running Venti on mirrored or raided disks. When a block on a mirrored pair doesn't match the block on its partner, the mirroring layer has no idea which one is right, but Venti does. Some way to export this read failure to it and give it a chance to decide which block to pick would be pretty neat. Alternatively, run one Venti per disk and run something like Inferno's vcache in front of each of them, each one naming the other as the 'remote' server... For more protection, I have an (currently stalled) 'devrs' started. It is based on Inferno's devds (Plan 9's devfs) in RAID1 mode, but protects each disk block with a (255,223) Reed-Solomon code and interleaves the coded blocks around the disks somewhat. Email me for sources; does this seem like a reasonable approach? Take care, -- vs