From: Goswin von Brederlow <goswin-v-b@web.de>
To: Asdo <asdo@shiftmail.org>
Cc: Goswin von Brederlow <goswin-v-b@web.de>,
Michael Evans <mjevans1983@gmail.com>,
Ryan Wagoner <rswagoner@gmail.com>,
Tim Bock <jtbock@daylight.com>,
linux-raid@vger.kernel.org
Subject: Re: Question about raid robustness when disk fails
Date: Wed, 27 Jan 2010 11:25:53 +0100 [thread overview]
Message-ID: <87wrz3zvwu.fsf@frosties.localdomain> (raw)
In-Reply-To: <4B6005DC.7070701@shiftmail.org> (asdo@shiftmail.org's message of "Wed, 27 Jan 2010 10:22:36 +0100")
Asdo <asdo@shiftmail.org> writes:
> Goswin von Brederlow wrote:
>> Michael Evans <mjevans1983@gmail.com> writes:
>>
>>> Why doesn't the kernel issue a pessimistic alternate 'read' path (on
>>> the other drives needed to obtain the data) if the ideal method is
>>> late. It would be more useful for time-sensitive/worst case buffering
>>> to be able to customize when to 'give up' dynamically.
>>>
>>
>> That is a verry good question. I look forward to seeing patches for this
>> from you. :) I think it isn't done because nobody has bothered to write
>> the code yet but maybe I'm wrong and it would make the code too
>> complicated.
>>
>
> This is probably more complicated than allowing a timeout to be set at
> the MD layer or block-device layer, isn't it?
There is a timeout at various levels already but for example the scsi
specs alow for quite some time till you give up, as in a minute. You
would certainly want something much much smaller here.
So from the top of my head here is what I imagine you need: You would
need to set a timeout for reading a block. Then once the timeout is
reached you need to read the rest of the stripe if not available
already. Do you ready every block in a stripe or just enough to get the
data? You might not need all blocks, e.g. a 3 way raid1 or a raid6
doesn't need all blocks. But then you have another timeout situation
there.
So lets say we read all blocks for simplicity sake. Then you might have
scheduled more reads than you need and when enough reads were
successfull you should not wait for the rest but return the data
imediatly. Late arrivals from extra reads (or the original) you then
have to also handle. Or do you cancel them? Also the original read might
succeed before the extra reads return.
It might also be wise to notice when additional reads are slower than
the original and if that happens often then increase the initial timeout
slightly. But a warning for the admin would do to so he can adjust the
timeout himself.
I don't think setting the timeout for the initial read will be
complicated but handling the alternatives will be not trivial. If yo
implement it you probably find more problems along the way.
> Which would be just as good I think.
>
> Is it possible to cancel a SATA/SCSI command that is being executed by
> the drive?
> (it's probably feasible only with NCQ disabled anyway, but it's easy
> to disable NCQ)
Do you want to do that? I would rather have the drive keep trying and
return an error if it can't read so the raid layer rewrites the blocks
causing it to be remapped. I do not want to wait for that but I want it
to happen.
> It's a pity we have to rely on TLER, this narrows the choice of drives
> a lot...
I don't. I just acknowledge the limitation and accept the downtime to
find and remove a broken but not properly failed disk. I use raid so I
don't loose my data when a disk fails, not primarily for availability.
So far I had one case in 10 years where a failing disk took down my
system.
MfG
Goswin
next prev parent reply other threads:[~2010-01-27 10:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-08 17:39 Question about raid robustness when disk fails Tim Bock
2010-01-22 16:32 ` Goswin von Brederlow
2010-01-25 16:22 ` Tim Bock
2010-01-25 17:51 ` Goswin von Brederlow
2010-01-25 18:12 ` Michał Sawicz
2010-01-26 7:29 ` Goswin von Brederlow
2010-01-27 0:19 ` Ryan Wagoner
2010-01-27 4:22 ` Michael Evans
2010-01-27 9:04 ` Goswin von Brederlow
2010-01-27 9:22 ` Asdo
2010-01-27 10:25 ` Goswin von Brederlow [this message]
2010-01-27 10:43 ` Asdo
2010-01-27 15:34 ` Goswin von Brederlow
2010-01-28 11:52 ` Michael Evans
2010-01-27 15:15 ` Tim Bock
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=87wrz3zvwu.fsf@frosties.localdomain \
--to=goswin-v-b@web.de \
--cc=asdo@shiftmail.org \
--cc=jtbock@daylight.com \
--cc=linux-raid@vger.kernel.org \
--cc=mjevans1983@gmail.com \
--cc=rswagoner@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox