Messages in this thread |  | | Subject | Re: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } | | From | Peter Osterlund <> | | Date | 23 Dec 2001 12:18:01 +0100 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |