From: Jens Axboe <axboe@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andre Hedrick <andre@linux-ide.org>,
Daniel Stodden <stodden@in.tum.de>,
linux-kernel@vger.kernel.org
Subject: Re: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Date: Thu, 27 Dec 2001 17:51:05 +0100 [thread overview]
Message-ID: <20011227175105.E1730@suse.de> (raw)
In-Reply-To: <20011227155403.A1730@suse.de> <E16JdbY-00061d-00@the-village.bc.nu>
In-Reply-To: <E16JdbY-00061d-00@the-village.bc.nu>
On Thu, Dec 27 2001, Alan Cox wrote:
> > retries belong at the low level, once you pass up info of failure to the
> > upper layers it's fatal. time for FS to shut down.
>
> Thats definitely not the case. Just because your file system is too dumb to
> use the information please don't assume everyone elses isnt - in fact one
> of the side properties of Daniel Phillips stuff is that it should be able
> to sanely handle a bad block problem.
That's ok too, the fs can do whatever it wants in case of I/O failure.
It's not up to the fs to reissue failed requests, _that's_ stupid.
> EVMS, MD, multipath all need to know about and do their own bad block
> handling. If the block driver knows how to recover stuff then great it
> can recover it, but we should ensure its possible for the fs internals
> to recover and work around a bad block.
Need to know, fine I'm not arguing with that. I don't want to hide
information from anyone.
> > Irk, software managed bad block remapping is horrible.
>
> IBM have it working, so however horrible doesn't matter that much, someone
> has done the work for you.
Then it must be The Right Thing.
I've written a block driver that handles (or wants to) bad block
remapping too, which just made me even more sure that this is definitely
a hw issue.
--
Jens Axboe
next prev parent reply other threads:[~2001-12-27 16:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-06 6:13 hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Daniel Stodden
2001-12-06 6:55 ` Sven.Riedel
2001-12-06 15:04 ` Matthias Andree
2001-12-23 7:24 ` Andre Hedrick
2001-12-23 7:53 ` Andrew Morton
2001-12-22 20:25 ` T. A.
2001-12-23 11:18 ` Peter Osterlund
2001-12-23 13:31 ` Alan Cox
2001-12-23 22:08 ` Andre Hedrick
2001-12-27 14:54 ` Jens Axboe
2001-12-27 16:42 ` Alan Cox
2001-12-27 16:51 ` Jens Axboe [this message]
2001-12-27 17:46 ` Linus Torvalds
2001-12-27 18:32 ` Andre Hedrick
2001-12-27 21:15 ` Legacy Fishtank
2001-12-27 17:50 ` Alan Cox
2001-12-28 2:05 ` Andre Hedrick
2001-12-28 10:59 ` Jens Axboe
2001-12-28 12:29 ` Rik van Riel
2001-12-28 12:33 ` Jens Axboe
2001-12-28 13:00 ` Jens Axboe
2001-12-28 19:30 ` Peter Osterlund
2001-12-29 15:07 ` Jens Axboe
2001-12-28 20:23 ` Andre Hedrick
2001-12-29 14:15 ` Jens Axboe
2001-12-29 20:58 ` You WIN Andre Hedrick
2001-12-31 12:58 ` Jens Axboe
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=20011227175105.E1730@suse.de \
--to=axboe@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andre@linux-ide.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stodden@in.tum.de \
/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.