All of lore.kernel.org
 help / color / mirror / Atom feed
From: Molle Bestefich <molle.bestefich@gmail.com>
To: linux-raid@vger.kernel.org
Subject: Re: RAID1 and data safety?
Date: Tue, 22 Mar 2005 09:48:57 +0100	[thread overview]
Message-ID: <62b0912f05032200484c21c265@mail.gmail.com> (raw)
In-Reply-To: <16959.18991.327224.545186@cse.unsw.edu.au>

Neil Brown wrote:
>> Is there any way to tell MD to do verify-on-write and
>> read-from-all-disks on a RAID1 array?
>
> No.
> I would have thought that modern disk drives did some sort of
> verify-on-write, else how would they detect write errors, and they are
> certainly in the best place to do verify-on-write.

Really?  My guess was that they wouldn't, because it would lead to
less performance.
And that's why read errors crop up at read time.

> Doing it at the md level would be problematic as you would have to
> ensure that you really were reading from the media and not from some
> cache somewhere in the data path.  I doubt it would be a mechanism
> that would actually increase confidence in the safety of the data.

Hmm.  Could hack it by reading / writing blocks larger than the cache.  Ugly.

> Imagine a filesystem that could access multiple devices, and where it
> kept index information it didn't just keep one block address, but
> rather kept two block address, each on different devices, and a strong
> checksum of the data block.  This would allow much the same robustness
> as read-from-all-drives and much lower overhead.

As in, "if the checksum fails, try loading the data blocks [again]
from the other device"?
Not sure why a checksum of X data blocks should be cheaper
performance-wise than a comparison between X data blocks, but I can
see the point in that you only have to load the data once and check
the checksum.  Not quite the same security, but almost.

> In summary:
>  - you cannot do it now.
>  - I don't think md is at the right level to solve these sort of problems.
>    I think a filesystem could do it much better. (I'm working on a
>    filesystem .... slowly...)
>  - read-from-all-disks might get implemented one day. verify-on-write
>    is much less likely.
> 
>> Apologies if the answer is in the docs.
> 
> It isn't.  But it is in the list archives now....

Thanks! :-)

(Guess I'll drop the idea for the time being...)

  reply	other threads:[~2005-03-22  8:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-16  9:13 RAID1 and data safety? Molle Bestefich
2005-03-21 22:26 ` Neil Brown
2005-03-22  8:48   ` Molle Bestefich [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-03-29  8:54 AW: AW: " Schuett Thomas EXT
2005-03-29  9:27 ` Peter T. Breuer
2005-03-29 10:09   ` Neil Brown
2005-03-29 11:26     ` Peter T. Breuer
2005-03-29 12:13       ` Lars Marowsky-Bree
2005-04-04 22:57       ` Doug Ledford
2005-03-29 10:08 ` AW: AW: " Neil Brown
2005-03-29 11:29   ` Peter T. Breuer
2005-03-29 16:46     ` Luca Berra
2005-03-29 18:43       ` Peter T. Breuer
2005-03-29 20:07     ` Mario Holbe
2005-04-04 20:06     ` Doug Ledford
2005-04-08 12:16       ` Peter T. Breuer
2005-04-07 15:35 AW: " Schuett Thomas EXT
2005-04-07 16:05 ` Doug Ledford
2005-04-10 17:54   ` Peter T. Breuer

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=62b0912f05032200484c21c265@mail.gmail.com \
    --to=molle.bestefich@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.