From: David Greaves <david@dgreaves.com>
To: David Lethe <david@santools.com>
Cc: Janos Haar <janos.haar@netcenter.hu>, linux-raid@vger.kernel.org
Subject: Re: questions about softraid limitations
Date: Sun, 18 May 2008 23:23:50 +0100 [thread overview]
Message-ID: <4830AC76.6050004@dgreaves.com> (raw)
In-Reply-To: <A20315AE59B5C34585629E258D76A97C6B3EEC@34093-C3-EVS3.exchange.rackspace.com>
David Lethe wrote:
> Hmm - I wonder if things like ddrescue could work with the md bitmaps to
> improve
> this situation?
> Is this related to David Lethe's recent request?
>
> -----------
> No, we are trying two different approaches.
> In my situation, I already know that the data is munged on a particular
> block, so the solution is to calculate the correct data from surviving
> parity, and just write the new value. There is no reason to worry about
> md bitmaps, or even whether or not there are 0x00 holes.
I think we (or I) may be talking about the same thing?
Consider an array sd[abcde] and a badblock (42) on sdb followed by a badblock
elsewhere (142) on sdc.
I would like to ddrescue sdb to sdb' and sdc to sdc' (leaving holes)
block 42 should be recovered from sd[acde] to sdb'
block 142 should be recovered from sd[abde] to sdc'
The idea was to possibly tristate the bitmap clean/dirty/corrupt.
If md gets a read/write error then it marks the block corrupt; alternatively we
could use the output from ddrescue to identify corrupt blocks that md may not
have seen.
I wondered whether each block actually needed to record the event it was last
updated with. I haven't thought through the various failure cases but...
> I am not trying to fix a problem such as a rebuild gone bad or an
> intermittent disk failure that put the md array in a partially synced,
> and totally confused state.
No, me neither...
> My desire is to limit damage before a full disk recovery needs to be
> performed, by insuring that there are no double-errors that will make
> stripe-level recovery impossible (assuming they aren't using RAID6).
> For that I need a mechanism to repair a stripe given a physical disk and
> offset. There is no completely failed disk to contend with, merely a
> block of bad data that will repair itself once I issue a simple write
> command. (trick, of course, is to figure out exactly what & where to
> right it and deal with potential locking issues relating to file
> system).
I think I'm describing that too.
If you simplify my case to a single badblock do we meet?
David
next prev parent reply other threads:[~2008-05-18 22:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-14 0:34 questions about softraid limitations Janos Haar
2008-05-14 10:45 ` David Greaves
2008-05-14 23:29 ` Janos Haar
2008-05-16 1:39 ` Neil Brown
2008-05-16 6:05 ` [OT] " Peter Rabbitson
2008-05-18 23:52 ` Neil Brown
2008-05-16 10:00 ` Janos Haar
2008-05-16 8:36 ` David Greaves
2008-05-16 9:18 ` David Greaves
2008-05-16 9:28 ` Janos Haar
2008-05-18 9:11 ` David Greaves
2008-05-18 11:11 ` Janos Haar
2008-05-18 13:00 ` David Greaves
2008-05-18 21:51 ` Janos Haar
2008-05-18 19:36 ` David Lethe
2008-05-18 22:23 ` David Greaves [this message]
2008-05-18 22:38 ` Janos Haar
-- strict thread matches above, loose matches on Subject: below --
2008-05-18 23:18 David Lethe
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=4830AC76.6050004@dgreaves.com \
--to=david@dgreaves.com \
--cc=david@santools.com \
--cc=janos.haar@netcenter.hu \
--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.