From: Molle Bestefich <molle.bestefich@gmail.com>
To: Guy <bugzilla@watkins-home.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Joys of spare disks!
Date: Wed, 2 Mar 2005 13:05:04 +0100 [thread overview]
Message-ID: <62b0912f05030204054b1ab8ae@mail.gmail.com> (raw)
In-Reply-To: <200503020552.j225qD513637@www.watkins-home.com>
Hm.. I said partial resync, because a full resync would be a waste of
time if it's just a thousand sectors or so that needs to be relocated.
Anyhow.
There's no overhead to the application with the (theoretically
"partial") degraded mode, since it happens in parallel.
The latency of doing it while the read operation is ongoing would be,
say, 3 seconds or so per bad sector on a standard disk? Imagine a
thousand bad sectors, and any sane person would quickly pull the plug
from the dead box and have it resync when it boots instead of staring
at a hung system. When that happens there's even the risk that the
resync fails completely, if md decides to pull one of the disks other
than the one with bad blocks on it from the array before it resyncs.
I prefer the first scenario (the system keeps running, the array isn't
potentially destroyed), even if it means a slightly lower I/O rate and
thus a minor overhead if and only if running applications utilize the
I/O subsystem 100%..
Am I wrong?
Guy wrote:
> I think the overhead related to fixing the bad blocks would be insignificant
> compared to the overhead of degraded mode.
>
> Guy
>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org
> [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Molle Bestefich
> Sent: Tuesday, March 01, 2005 10:51 PM
> To: linux-raid@vger.kernel.org
> Subject: Re: Joys of spare disks!
>
> Robin Bowes wrote:
> > I envisage something like:
> >
> > md attempts read
> > one disk/partition fails with a bad block
> > md re-calculates correct data from other disks
> > md writes correct data to "bad" disk
> > - disk will re-locate the bad block
>
> Probably not that simple, since some times multiple blocks will go
> bad, and you wouldn't want the entire system to come to a screeching
> halt whenever that happens.
>
> A more consistent and risk-free way of doing it would probably be to
> do the above partial resync in a background thread or so?..
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2005-03-02 12:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-28 14:24 Joys of spare disks! Robin Bowes
2005-02-28 15:04 ` Jon Lewis
2005-02-28 15:23 ` Robin Bowes
2005-02-28 15:54 ` Nicola Fankhauser
2005-02-28 17:04 ` Robin Bowes
2005-02-28 18:58 ` Nicola Fankhauser
2005-02-28 19:25 ` Robin Bowes
2005-03-02 2:48 ` Robin Bowes
2005-03-02 2:59 ` Neil Brown
2005-03-02 3:50 ` Molle Bestefich
2005-03-02 3:52 ` Molle Bestefich
2005-03-02 5:52 ` Guy
2005-03-02 12:05 ` Molle Bestefich [this message]
2005-03-02 16:16 ` Guy
2005-03-03 9:37 ` Molle Bestefich
2005-03-02 4:57 ` Brad Campbell
2005-03-02 5:53 ` Guy
[not found] ` <eaa6dfe0503080915276466a1@mail.gmail.com>
2005-03-08 17:15 ` Derek Piper
[not found] ` <200503091704.j29H4l517152@www.watkins-home.com>
2005-03-10 19:24 ` Derek Piper
-- strict thread matches above, loose matches on Subject: below --
2005-03-07 16:36 LinuxRaid
2005-03-07 17:09 ` Peter T. Breuer
2005-03-07 20:15 LinuxRaid
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=62b0912f05030204054b1ab8ae@mail.gmail.com \
--to=molle.bestefich@gmail.com \
--cc=bugzilla@watkins-home.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 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).