All of lore.kernel.org
 help / color / mirror / Atom feed
From: pg@raid.list.sabi.co.UK (Peter Grandi)
To: list Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: SSD based sw RAID: is ERC/TLER really important?
Date: Sun, 25 Jul 2021 12:28:17 +0200	[thread overview]
Message-ID: <24829.15553.689641.666563@cyme.ty.sabi.co.uk> (raw)
In-Reply-To: <e4ecfd01-cffc-f154-5f7c-5ca08a12fd33@turmel.org>

>> * The purpose of having a long device error retry is to instead to
>> minimize the chances of declaring a drive failed, hoping that many
>> retries succeed. (but note the difference between reads and writes).
>> * It is possible to set the kernel timeouts higher than device retry
>> periods, if one does not care about latency, to minimize the
>> chances of declaring a drive failed (not[e] the difference
>> between Linux command timeouts and retry timeouts, the latter
>> can also be long).

> You understanding is incorrect.
> Read errors do *not* kick drives out. It takes several read
> errors in a short time to fail a drive out of an array.

I am sorry that I was not clear enough and therefore:

* You failed to understand the relevance of "note the difference
  between reads and writes" which I added precisely because I
  guessed that someone unfamiliar with storage device would need
  that terse qualifier.

* You failed to understand the relevance of the "to minimize the
  chances of declaring a drive failed".

* You failed to realize that I was addressing tersely the
  original poster's case of a drive being declared failed
  because of a drive timeout longer than the kernel command
  timeout, without going in detail about all other possible
  cases.

  parent reply	other threads:[~2021-07-25 10:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-24 18:41 SSD based sw RAID: is ERC/TLER really important? Gianluca Frustagli
2021-07-24 20:19 ` Peter Grandi
2021-07-24 21:45   ` Phil Turmel
2021-07-25  7:00     ` Wols Lists
2021-07-25 10:28     ` Peter Grandi [this message]
2021-07-26  1:06       ` Phil Turmel
2021-07-26  7:57         ` Peter Grandi
2021-07-26 16:12           ` Peter Grandi
2021-07-25 11:04     ` Peter Grandi
2021-07-24 20:21 ` Andy Smith

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=24829.15553.689641.666563@cyme.ty.sabi.co.uk \
    --to=pg@raid.list.sabi.co.uk \
    --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.