From: sct@dcs.ed.ac.uk (Stephen Tweedie) Subject: Re: bad blocks Date: 15 Mar 1993 04:58:45 GMT
In article <1993Mar11.155117.1370@prime.mdata.fi>, kennu@mits.mdata.fi (Kenneth Falck) writes:
> Argh... I feel kind of stupid for not realizing how the bad block
> scheme is supposed to work earlier... So obviously, the controller has
> two different ways of reporting a bad block, depending on whether the
> block has been marked bad during the low level format, or whether it
> has gone bad after that. I didn't quite realize the relation between
> the controller retry-bug and this.
> But hey, I still have a couple of suggestions or ideas.
> 1. Since the 16-time retry is obviously designed to allow data recovery
> if a block goes bad (?), maybe it should only take place if the kernel
> is trying to READ data, not WRITE. And accordingly, mk*fs should use
> write() instead of read() to detect bad blocks. Does this sound bad,
> am I totally clueless again.. :-? I'm not very familiar with the way
> the HD-controller is programmed, so it might be what I'm suggesting
> is not possible.
Unfortunately, the kernel has no facility for doing synchronous
writes; when a user process writes, it just gets buffered for physical
writing later on. There is currently no way for a user process to
obtain the physical disk address of a failed write.
> 2. If there are a lot of people like me with a buggy controller, maybe
> there could be a BUGGY_OLD_CONTROLLER #define in the Makefile, which
> would set MAX_ERRORS automatically to 1? It doesn't really matter to
> me anymore, since now I know several ways to get past the problem, but
> other people might get into trouble and have to ask about it.
>
Definitely a good idea. I'm not quite sure where it should go,
though; it might be deemed too obscure to fit the standard "make
config" configuration script.
Cheers,
Stephen Tweedie.