> > i feel like the media isn`t downgrading because
> > the badblocks _arent_ physical: low-level drive
> > reformat doesnt show anything.
> the low-level format merely remaps bad blocks to spare ones.
> eventually, you'll run out of spare blocks, and then...
no no no - when ibm DFT (drive fitness test)
runs on physical bblks i _hear_ this! (and also
it tells me).
also how do you like _continuous_ 100-200 - large
zone of bblks, and _nothing_ more!
it these were real bblks, they appears like
dots on surface, thus killing _physically_ neighbouring
sectors of _different_ cylinders, so there should be
some cyclic pattern of them.
And in my case the is not pattern - there is only
a sequence of 100-200 bblks...
You ask how do i know this? I had wrote a modification
to debugreiserfs which in early versions scanned
journal for bblks and zeroified them, so they
are remapped(?), and later i rewroted it to scan
the whole drive, so i know here the situation...
> but the whole point of checksum errors is that the corrupted
> transfer is discarded and retried. just like with TCP or UDP.
okay, i`d selected the wrong exmple, but
imagine:
1. drive gets data over udma along with crc.
2. drive checks crc(data) with crc_from_udma_cable,
and it is okay.
3a. drive corrupts data.
4a. drive writes the corrupted data, with right crc.
3b. drive corrupts crc.
4b. drive writes the right data with corrupted crc.
The only assumption here is needed, is that
these corruptions belongs only to the udma-specific
process... (e.g why UDMA?)
> also, aren't the corruptions to specific blocks? the kind
> of checksum failure you're talking about would be uniformly
> distributed over all transfers, not sector-specific.
internal drive super-optimizing firmware is black magik... (remember pentium-math issues?)
---cheers,
Samium Gromoff - 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/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:19 EST