From: John Robinson <john.robinson@anonymous.org.uk>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: RFC: detection of silent corruption via ATA long sector reads
Date: Sun, 04 Jan 2009 13:49:23 +0000 [thread overview]
Message-ID: <4960BE63.3040608@anonymous.org.uk> (raw)
In-Reply-To: <4960AC15.8030207@anonymous.org.uk>
On 04/01/2009 12:31, John Robinson wrote:
> On 04/01/2009 07:37, Martin K. Petersen wrote:
[...]
>> We also don't want to do checksumming at every layer. That's going to
>> suck from a performance perspective. It's better to do checksumming
>> high up in the stack and only do it once. As long as we give the upper
>> layers the option of re-driving the I/O.
>>
>> That involves adding a cookie to each bio that gets filled out by DM/MD
>> on completion. If the filesystem checksum fails we can resubmit the I/O
>> and pass along the cookie indicating that we want a different copy than
>> the one the cookie represents.
>
> I'd like to understand this mechanism better; at first glance it's
> either going to be too simplistic and not cover the various block layer
> cases well, or it means you end up re-implementing RAID and LVM in the
> filesystem.
I've thought about this again, and I'm wrong; there may be complications
in handling the cookies up and down the stack where more than one layer
thinks it knows how to have another go, but I can see what you describe
as being useful and relatively device-agnostic.
I wonder if there might also be scope for cookies going down through the
stack to carry an indication of how hard to try; some filesystems or
other consumers of block devices may be willing to ask again or want to
be told about problems quickly (e.g. btrfs over RAID over TLER-equipped
discs), while some may need best efforts all out first time because they
can't cope will failure returns (e.g. FAT over cheap IDE discs).
Anyway, I think I'd better leave all this to the experts i.e. you :-)
Cheers,
John.
next prev parent reply other threads:[~2009-01-04 13:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.8mwKV7y4hm+Q6mvIKtp9QGoJYUU@ifi.uio.no>
[not found] ` <fa.4QcsYZC0gJJwJ0eUOht3hDYaVWs@ifi.uio.no>
2008-12-28 22:40 ` RFC: detection of silent corruption via ATA long sector reads Sitsofe Wheeler
2008-12-30 13:48 ` Mark Lord
2009-01-02 20:26 ` Greg Freemyer
2009-01-02 20:43 ` Sitsofe Wheeler
2009-01-02 21:05 ` Greg Freemyer
2009-01-02 22:04 ` Martin K. Petersen
2009-01-02 22:41 ` Greg Freemyer
2009-01-03 3:01 ` Martin K. Petersen
2009-01-03 13:20 ` John Robinson
2009-01-04 7:37 ` Martin K. Petersen
2009-01-04 12:31 ` John Robinson
2009-01-04 13:49 ` John Robinson [this message]
2009-01-05 2:43 ` Martin K. Petersen
2009-01-05 2:45 ` Martin K. Petersen
2009-01-05 3:24 ` NeilBrown
2008-12-26 21:44 Greg Freemyer
2008-12-26 22:15 ` Robert Hancock
2008-12-26 22:15 ` Robert Hancock
2008-12-28 22:26 ` Mark Lord
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=4960BE63.3040608@anonymous.org.uk \
--to=john.robinson@anonymous.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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.