On Wed, 12 Apr 2000, Horst von Brand wrote:
> Ed Carp <erc@pobox.com> said:
>
> [...]
>
> > It must be nice to live in such a perfect world where one can replace disks
> > instantly at the first sign of a problem. Why have such badblock code in the
> > kernel in the first place -- just insist that all your users have error-free
> > drives.
>
> > But out here in the real world we don't have such a luxury. It could be days
> > before a drive can get replaced. In the meantime, we have to make do.
>
> In my experience, once a drive starts showing errors you don't have
> days. You have a few hours of working time left, if you are lucky a
> day. Then the drive (and the data on it) is gone for good. Given that,
> what they are saying (if harsh) is more than reasonable.
> --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
Reading this thread, I see that many have a misconception. Bad blocks
will not be found when someone tries to write to a bad sector! As
long as the sector header exits, or in some drives, as long as the
time-slot where it should be exists, the write will succeed. This
"feature" was used in the "olden" days to verify that a "key disk"
was present in "DOS drive A:". The program would try to write to a
bad sector on a particular track. The write would succeed, but a
subsequent read would fail. This showed that you had the key-disk
with the laser-hole burned into it at the right place.
To see if a write succeeded, would require that every sector written
would have to be read back. This would more than double disk access
time!
In principle, there is no difference between how hard disks and
floppy disks handle writes. Smart hard disks "learn" where every
sector is (they may not be 1:1 interleaved). If you are going to
write to sector C, and the hard disk has learned that it follows
sector A, immediately after reading the CRC of A, at the start of
the write-splice for the following sector, it turns on the write-
current, writes the sync preamble, the header, the data, then the
CRC. The write current, with a sync-pattern tails-off into the
next write-splice area. The sector just written, is not read back.
This would require waiting for it to come around the next time.
The solution to bad blocks remains, as it has always been, to
occasionally execute a utility to clean up the disk. Ted showed
how to do this. The problem remains that the data within these
bad-blocks are BAD even if you ignore the CRC (read-long allows this).
I would like to see the bad-blocks owned by a visible file as was
done under VMS. You could run a cleanup-utility via crond and
not even think about it. Then once a week you do:
Script started on Wed Apr 12 10:52:10 2000
# ls -la BAD*
-Q-------- 1 root root 77762560 Apr 12 10:51 BADBLOCKS.SYS
# exit
exit
Script done on Wed Apr 12 10:52:23 2000
And you say; "Holy Cow! It's time to get a new disk!"
Cheers,
Dick Johnson
Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:18 EST