From: NeilBrown <neilb@suse.de>
To: "." <desire@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: software raid and ERC
Date: Wed, 18 Apr 2012 13:52:10 +1000 [thread overview]
Message-ID: <20120418135210.24ff8db5@notabene.brown> (raw)
In-Reply-To: <CAAevFRRh2YiQOe1cbEFc+wY8UnBCEMAvrLdBsQLzfWt-6URpXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]
On Wed, 18 Apr 2012 11:12:57 +0800 "." <desire@gmail.com> wrote:
> Apart from the behaviour of the SCSI layer, does the linux software
> raid layer have any concept of timeouts that would cause a drive to be
> kicked when performing a deep recovery cycle? A storagereview forum
> thread [3] claims that the linux software raid layer does not have a
> concept of timeouts and does not care about ERC. In a web article [4]
> the major NAS manufacturers that use software raid seem to agree with
> this stance.
Linux software RAID does not have a concept of timeouts.
>
> On the other hand, how I interpret a previous post from Stefan [5] is
> that the linux raid layer does have its own timeout mechanism that
> will kick a non-responding drive.
That aspect of that post is inaccurate.
>
> > Without ERC-timeout, the drive tries to correct the error on
> > its own (not reacting on any requests), mdraid assumes an error after a
> > while and tries to rewrite the "missing" sector (assembled from the
> > other disks). But the drive will still not react to the write request
> > as it is still doing its internal recovery procedure. Now mdraid
> > assumes the disk to be bad and kicks it.
>
> Since I can't read code, I'm hoping that this list where software raid
> development takes place would be able to clear up whether
>
> a. Do delays caused by deep recovery cycles actually have any direct
> impact on the linux software raid layer, or does it simply issue a
> command to the underlying storage/scsi subsystem and block until there
> is a response?
md/raid in linux simply issues a command and waits for it to complete, either
with success or failure.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2012-04-18 3:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAAevFRRuGc6x4hJax-kM8ncW9=873aRnjN-WWkoheYD7r6jimA@mail.gmail.com>
2012-04-17 14:05 ` software raid and ERC .
2012-04-17 17:47 ` Emmanuel Noobadmin
2012-04-18 2:08 ` Phil Turmel
2012-04-18 3:12 ` .
2012-04-18 3:52 ` NeilBrown [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=20120418135210.24ff8db5@notabene.brown \
--to=neilb@suse.de \
--cc=desire@gmail.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 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.