From: Goswin von Brederlow <goswin-v-b@web.de>
To: Matthias Urlichs <matthias@urlichs.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Re-map disk sectors in userspace when rewriting after read errors
Date: Wed, 16 Sep 2009 11:41:15 +0200 [thread overview]
Message-ID: <87ws3z5iro.fsf@frosties.localdomain> (raw)
In-Reply-To: <h8nreb$n8p$4@ger.gmane.org> (Matthias Urlichs's message of "Tue, 15 Sep 2009 10:48:43 +0000 (UTC)")
Matthias Urlichs <matthias@urlichs.de> writes:
> On Tue, 15 Sep 2009 08:37:52 +0100, Alex Butcher wrote:
>
>> Either way, it's not
>> suitable for data I even care a little bit about.
>
> Ordinarily I'd agree with you. In this case, however, the data is mostly
> read-only and on backup media. So I don't really care if the disks fall
> off the edge of a cliff; the data will survive.
>
> I can justify a moderate amount of time working on this, with the
> hardware I have. I can't really justify buying eight new disks.
>
> NB: Please don't dismiss this kind of setup out of hand. I know that
> disks are cheap enough these days that the typical professional user
> won't ever need to worry about not being able to replace hardware which
> behaves like this. However, many people happen to be in a different
> situation. :-/
How about making it re-read repaired blocks so it catches when the
disk didn't remap?
I'm assuming the following happens:
1) disk read fails
2) raid rebuilds the block from parity
3) raid writes block to bad disk
4) disk writes data to the old block and fails to detect a write error
that would trigger a rempapping
5) re-read of the data succeeds because the data is still in the
drives disk cache
6) later read of the data fails because nothing was remapped
So you would need to write some repair-check-daemon that remembers
repaired blocks, waits for enough data to have passed through the
drive to flush the disk cache and then retries the block again.
And again and again till it stops giving errors.
Alternatively write a re-map device-mapper target that reserves some
space of the disk and remaps bad blocks itself.
MfG
Goswin
next prev parent reply other threads:[~2009-09-16 9:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-15 6:23 Re-map disk sectors in userspace when rewriting after read errors Matthias Urlichs
2009-09-15 6:45 ` berk walker
2009-09-15 7:23 ` Matthias Urlichs
2009-09-15 7:13 ` Alex Butcher
2009-09-15 7:29 ` Matthias Urlichs
2009-09-15 7:37 ` Alex Butcher
2009-09-15 10:48 ` Matthias Urlichs
2009-09-16 9:41 ` Goswin von Brederlow [this message]
2009-09-16 13:13 ` Matthias Urlichs
2009-09-18 8:17 ` Majed B.
2009-09-18 8:28 ` Robin Hill
2009-09-18 9:57 ` Majed B.
2009-09-18 10:22 ` Robin Hill
2009-09-18 10:52 ` Majed B.
2009-09-18 11:15 ` Robin Hill
2009-09-18 11:35 ` Matthias Urlichs
2009-09-18 17:44 ` John Robinson
2009-09-18 18:02 ` Greg Freemyer
2009-09-18 20:13 ` Majed B.
2009-10-02 13:55 ` Bill Davidsen
2009-09-15 10:40 ` Majed B.
2009-09-15 10:52 ` Matthias Urlichs
2009-09-15 11:03 ` Majed B.
2009-09-15 17:02 ` Majed B.
2009-09-15 18:05 ` Matthias Urlichs
2009-09-15 18:14 ` Majed B.
2009-09-15 18:44 ` Matthias Urlichs
2009-09-16 9:31 ` Majed B.
2009-09-16 9:44 ` Matthias Urlichs
2009-09-16 9:52 ` Majed B.
2009-09-16 13:05 ` Alex Butcher
2009-09-16 10:00 ` Robin Hill
2009-09-16 10:07 ` Majed B.
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=87ws3z5iro.fsf@frosties.localdomain \
--to=goswin-v-b@web.de \
--cc=linux-raid@vger.kernel.org \
--cc=matthias@urlichs.de \
/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).