From: "Stefan Hübner" <stefan.huebner@stud.tu-ilmenau.de>
To: linux-raid@vger.kernel.org
Subject: Re: Feature Request
Date: Tue, 09 Feb 2010 15:19:58 +0100 [thread overview]
Message-ID: <4B716F0E.7040306@stud.tu-ilmenau.de> (raw)
In-Reply-To: <4B7154DA.90405@msgid.tls.msk.ru>
Am 09.02.2010 13:28, schrieb Michael Tokarev:
> Stefan *St0fF* Huebner wrote:
> []
>> Now imagine any RAID with some kind of redundancy, reading/writing
>> data. One of the disks finds out "I cannot correctly read/write the
>> requested sector", starts its error correction, hits the respective
>> ERC-timeout and reports back a media error or unrecoverable error. Now
>> mdraid would drop the disk.
>>
>> But actually the data of the sector can be recreated through the
>> existing redundancy. Wouldn't it be a smart thing if the mdraid
>> recreates the sector and just tried to write it again? And after a good
>> amount of failed retries it may well drop the disk.
>
> This is exactly what md layer is doing. On failed _read_ it tries to
> reconstruct data from other disk drives and writes the reconstructed
> data back to the drive where read failed. If the _write_ fails md will
> drop the disk.
Hi Mjt,
I hoped so - great it is implemented like that.
Well, then all that's needed is the check at assembly/creation time:
- (is the drive an ATA-drive) && (does it support SCT ERC)
-> and if it does, set some reasonable timeouts. (like the 7s it is with
enterprise class drives for reading. For writing I would suggest 14s,
bearing in mind that too quick reallocation results in the spare sectors
running out quickly.)
The writing back (I guess this is done with a reasonable amount of
retries) does not make sense if the drive is still in its error recovery
procedure and does not react to any commands until it is done.
P.S.: I have already implemented the checks and setup, but in userspace
using SG_IO.
/st0ff
>
> /mjt
> --
> 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
prev parent reply other threads:[~2010-02-09 14:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 8:43 Feature Request Stefan *St0fF* Huebner
2010-02-09 12:28 ` Michael Tokarev
2010-02-09 14:19 ` Stefan Hübner [this message]
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=4B716F0E.7040306@stud.tu-ilmenau.de \
--to=stefan.huebner@stud.tu-ilmenau.de \
--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).