From: Ric Wheeler <ric@emc.com>
To: Tejun Heo <htejun@gmail.com>, Neil Brown <neilb@cse.unsw.edu.au>
Cc: Mark Lord <mlord@pobox.com>,
Linux-ide <linux-ide@vger.kernel.org>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: faulty disk testing
Date: Tue, 05 Sep 2006 11:48:15 -0400 [thread overview]
Message-ID: <44FD9C3F.1030803@emc.com> (raw)
In-Reply-To: <44FD9022.5060208@gmail.com>
Tejun Heo wrote:
> Ric Wheeler wrote:
>
>>> One of the problems is that currently libata EH can take some minutes
>>> recovering from an error condition. With partial request retry from
>>> sd, a batch of consecutive bad sectors can make recovery take a
>>> really long time. This needs fixing.
>>
>>
>> So far, the new-init build has been running the recovery in the lab
>> for about 40 minutes ;-)
>
>
> Ouch. that's long. BTW, from the log you posted.
>
> sd 1:0:0:0: SCSI error: return code = 0x08000002
> sdb: Current: sense key: Medium Error
> Additional sense: Unrecovered read error - auto reallocate failed
> end_request: I/O error, dev sdb, sector 272900
> Buffer I/O error on device sdb3, logical block 208640
> Buffer I/O error on device sdb3, logical block 208641
> Buffer I/O error on device sdb3, logical block 208642
> Buffer I/O error on device sdb3, logical block 208643
> Buffer I/O error on device sdb3, logical block 208644
> Buffer I/O error on device sdb3, logical block 208645
> Buffer I/O error on device sdb3, logical block 208646
> Buffer I/O error on device sdb3, logical block 208647
>
> This is sd failing the request and the error completion propagating
> through fs/buffer and thus back to its user - probably md. It's a bit
> weird that md doesn't drop the device at this point. I think it could
> be that special metadata path thing you mentioned.
Neil, any special paths in MD (mainline MD) that would not kick out a
failing drive (drive superblock probe time)?
Thanks!
ric
prev parent reply other threads:[~2006-09-05 15:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-05 1:30 faulty disk testing Ric Wheeler
2006-09-05 11:57 ` Tejun Heo
2006-09-05 12:46 ` Ric Wheeler
2006-09-05 13:48 ` Mark Lord
2006-09-05 14:08 ` Tejun Heo
2006-09-05 14:15 ` Mark Lord
2006-09-05 14:45 ` Tejun Heo
2006-09-05 14:19 ` Ric Wheeler
2006-09-05 14:56 ` Tejun Heo
2006-09-05 15:48 ` Ric Wheeler [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=44FD9C3F.1030803@emc.com \
--to=ric@emc.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=mlord@pobox.com \
--cc=neilb@cse.unsw.edu.au \
/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.