All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Christensen <jdc@uwo.ca>
To: linux-raid@vger.kernel.org
Subject: Re: devices get kicked from RAID about once a month
Date: Fri, 04 Jun 2010 09:30:09 -0400	[thread overview]
Message-ID: <874ohjlyce.fsf@uwo.ca> (raw)
In-Reply-To: 20100604073304.1d669f45@notabene.brown

Neil Brown <neilb@suse.de> writes:

> On Thu, 03 Jun 2010 12:47:39 -0400 Dan Christensen <jdc@uwo.ca> wrote:
>
>> That could be useful.  And, as Neil said, if the SATA driver could be
>> told to use longer timeouts, that might help.  Neil, if you think that's
>> a good idea, maybe you could put the request in with the SATA folks?
>
> It might be a good idea.

After thinking about it more, I'm not sure I fully understand the
situation.  

If I was able to turn on something like TLER on the drives, so read
errors failed more quickly, what would the raid layer do when it got
a read error? 

If the raid layer handles this in a clever way (and I recall some
discussions about this), e.g. by reconstructing the data and rewriting
the sector allowing the drive to remap it, then what I don't fully
understand is why it doesn't also do this when there is a timeout on a
read.  Is it because timeouts can indicate more serious problems?  Even
so, wouldn't it be reasonable for the raid layer to give the drive a
second chance before assuming it has failed?

These questions are motivated from the following logic.  Since it is
generally recognized that quicker read errors (e.g. TLER) are good
for drives in a raid array, *increasing* the SATA timeouts seems like it
is going in the wrong direction.  Wouldn't it be better to have short
timeouts, but have the raid layer treat a timeout less seriously?

Dan


  reply	other threads:[~2010-06-04 13:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02 14:14 devices get kicked from RAID about once a month Dan Christensen
2010-06-02 15:02 ` rsivak
2010-06-02 15:29   ` Dan Christensen
2010-06-02 15:37     ` John Robinson
2010-06-02 16:33       ` Dan Christensen
2010-06-02 17:42         ` Bill Davidsen
2010-06-02 17:49           ` Dan Christensen
2010-06-03 16:37             ` Bill Davidsen
2010-06-03 16:47               ` Dan Christensen
2010-06-03 21:33                 ` Neil Brown
2010-06-04 13:30                   ` Dan Christensen [this message]
2010-06-04 13:50                     ` Robin Hill
2010-06-04 15:56                       ` Dan Christensen
2010-06-02 19:55 ` Miha Verlic
  -- strict thread matches above, loose matches on Subject: below --
2010-06-02 18:29 Stefan /*St0fF*/ Hübner
2010-06-03  0:13 ` Neil Brown
2010-06-03 17:00   ` Bill Davidsen

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=874ohjlyce.fsf@uwo.ca \
    --to=jdc@uwo.ca \
    --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.