public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox