On Thu, 13 Apr 2000, Richard B. Johnson wrote:
> On Thu, 13 Apr 2000, Khimenko Victor wrote:
>
> > In <200004131418.JAA02172@khijol.org> Ed Carp (erc@pobox.com) wrote:
> > > 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.
> [SNIPPED...]
>
> I'll be damned if I know how 'they' re-map in any reliable way.
They are using ECC. And it's NOT "reliable way". It works most of time.
But I've SEEN badblock on my "auto-remappable" IBM-DJNA-371350. Of course
this badblock "magically disappered" after write.
> I just took apart a SEAGATE ST321741W (small SCSI hard disk), and
> wrote the whole drive with a sheet of paper under head 1. Head 0
> will fail, apparently because it uses its data for servo. There
> were no failures on the write. This shows that, with this disk,
> there is not a read/after/write to verify it got there.
>
> If you have an old drive, you might want to try this too. It's
> very interesting -- the BS that marketing departments come up
> with (up with which they come..).
>
-
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:22 EST