Stephen C. Tweedie (sct@redhat.com) writes:
> > The problem with this approach is, if you're working with systems that are up 24x7, to *not* have the ability to automatically detect a bad block, copy the data to another block, then mark that block as bad is a real pain at best and completely unacceptable at worst. One of my clients is using Linux in a network communications controller (SONET/ATM backplane) and this sort of thing is going to raise the pain level around here as soon as someone realizes that badblocks aren't taken case of.
> Huh? Modern disks do this for you anyway. It is counterproductive
> for the kernel to try to help, because if the kernel remaps what appears
> to be a bad block, then you're just duplicating effort. The next time
> the kernel tries to write to that "bad" block, the disk will have
> remapped it on its own.
Most modern disks do this for you *transparently* - the driver doesn't even
see the error, so this does't really apply. If the kernel sees an error, it's
a real error, as opposed to one that has been remapped.
> And if you exhaust the size of the disk's remapping tables, you are
> in big trouble because your disk is on its way to the big data center
> in the sky.
Not entirely true in all cases - I've got drives that develop a bad block or
two every year or so, and they've been in service for at least 3 years.
Perhaps I've got one of those drives that doesn't do the remapping for me.
-
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:21 EST