From: Peter Osterlund <petero2@telia.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: Andre Hedrick <andre@linux-ide.org>,
Ben Fennema <bfennema@falcon.csc.calpoly.edu>,
linux-kernel@vger.kernel.org
Subject: Re: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Date: 23 Dec 2001 12:18:01 +0100 [thread overview]
Message-ID: <m2zo4ayyl2.fsf@ppro.localdomain> (raw)
In-Reply-To: <87d71s7u6e.fsf@bitch.localnet> <Pine.LNX.4.10.10112222312030.8976-100000@master.linux-ide.org> <3C258D76.BE259944@zip.com.au>
In-Reply-To: <3C258D76.BE259944@zip.com.au>
Andrew Morton <akpm@zip.com.au> writes:
> Andre Hedrick wrote:
> >
> > Would it be great if Linux did not have such a lame design to handle the
> > these problems? Just imaging if we had a properly formed
> > FS/BLOCK/MAIN-LOOP/LOW_LEVEL model; whereas, an error of this nature in a
> > write to media failure could be passed back up the pathway to the FS and
> > request the FS to re-issue the storing of data to a new location.
> >
> > To bad the global design lacks this ablitity and I suspect that nobody
> > gives a damn, or even worse ever thought of this idea.
>
> For the filesystems with which I am familiar, this feature would
> be quite difficult to implement. Quite difficult indeed. And given
> that it only provides recovery for write errors, its value seems
> questionable.
...
> What percentage of disk errors occur on writes, as opposed to reads?
> If errors-on-writes preponderate then maybe you're on to something.
> But I don't think they do?
One case were write errors are probably much more common than read
errors is packet writing on CDRW media. CDRW disks can only do a
limited number of writes to a given sector, and being able to remap
sectors on write errors can greatly increase the time a CDRW disk
remains usable.
The UDF filesystem has some code for bad block relocation
(udf_relocate_blocks) and the packet writing block "device" (it's a
layered device driver, somewhat like the loop device) has hooks for
requesting block relocation on I/O errors. This code is not working
yet though, and it seems quite complicated to get the relocation to
work properly when the file system is operating in asynchronous mode.
--
Peter Österlund petero2@telia.com
Sköndalsvägen 35 http://w1.894.telia.com/~u89404340
S-128 66 Sköndal +46 8 942647
Sweden
next prev parent reply other threads:[~2001-12-23 11:18 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 [this message]
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
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=m2zo4ayyl2.fsf@ppro.localdomain \
--to=petero2@telia.com \
--cc=akpm@zip.com.au \
--cc=andre@linux-ide.org \
--cc=bfennema@falcon.csc.calpoly.edu \
--cc=linux-kernel@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.