9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Venkatesh Srinivas <me@acm.jhu.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] fossil/venti falling down?
Date: Wed, 24 Jun 2009 20:00:08 -0400	[thread overview]
Message-ID: <f75780240906241700g5e00df10ke9498406e9fe84d6@mail.gmail.com> (raw)
In-Reply-To: <b0d4d576c13b85a456b77ca2dd5bc8ee@coraid.com>

On Wed, Jun 24, 2009 at 7:39 PM, erik quanstrom<quanstro@coraid.com> 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



  reply	other threads:[~2009-06-25  0:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18 16:01 John Floren
2009-06-18 16:21 ` John Floren
2009-06-18 16:25   ` erik quanstrom
2009-06-18 16:30     ` John Floren
2009-06-18 16:45       ` erik quanstrom
2009-06-18 17:10         ` John Floren
2009-06-24 17:06           ` John Floren
2009-06-21 11:57   ` Richard Miller
2009-06-21 12:12     ` Steve Simon
2009-06-21 14:11     ` erik quanstrom
2009-06-21 19:50       ` Josh Wood
2009-06-24 17:43 ` John Floren
2009-06-24 19:09   ` cinap_lenrek
2009-06-24 23:33     ` John Floren
2009-06-24 23:39       ` erik quanstrom
2009-06-25  0:00         ` Venkatesh Srinivas [this message]
2009-06-25  0:42           ` erik quanstrom
2009-06-25 16:13             ` Russ Cox
2009-06-25 16:24               ` erik quanstrom
2009-06-25 16:47                 ` Russ Cox
2009-06-25 16:51                   ` erik quanstrom
2009-06-25  0:59     ` erik quanstrom
2009-06-25 16:13       ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f75780240906241700g5e00df10ke9498406e9fe84d6@mail.gmail.com \
    --to=me@acm.jhu.edu \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).