Linux-kernel mailing list archive 2000-15,: Re: EXT2 and BadBlock updating.....

# Re: EXT2 and BadBlock updating.....

Khimenko Victor (khim@sch57.msk.ru)
Thu, 13 Apr 2000 21:23:58 +0400 (MSD)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alejandro Conty: "the ide problem"
- Previous message: Martin Josefsson: "Oops in 2.3.99pre5"
- Maybe in reply to: Andre Hedrick: "EXT2 and BadBlock updating....."
- Next in thread: Richard B. Johnson: "Re: EXT2 and BadBlock updating....."
- Reply: Richard B. Johnson: "Re: EXT2 and BadBlock updating....."
- Reply: Andre Hedrick: "Re: EXT2 and BadBlock updating....."

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.

>> 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.

No. You are WRONG. I've seen bad block here with my IBM-DJNA-371350 once.
Win98 seen it, Linux seen it, WinNT seen it. After I written new information
on that block it disappered. How it's possible ? Simple. If information was
stored and THEN disk got bad block you have NO choices but to get user-visible
error (information is GONE, no way to recover it!). But you can save new
information in the same place and drive will remap block on THAT stage.

>> 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.

See above. "Transparent remapping" does not mean that you will NEVER see
bad blocks. Just you can ignore issue completely: if information is gone
it's GONE -- you can not do anything (ok, you can pray :-). But when NEW
information will be stored it'll be put in different, working block. This
is what "transparent remapping" mean. And yes, any advanced scheme applied
on top of SUCH drive can only make situation WORSE, not better. And since
most modern drives are designed this way...

P.S. Of course if information was read when block was not "fully bad" and
drive was able to recover it with ECC it'll remap everything completly
transparent.

-
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/

- Next message: Alejandro Conty: "the ide problem"
- Previous message: Martin Josefsson: "Oops in 2.3.99pre5"
- Maybe in reply to: Andre Hedrick: "EXT2 and BadBlock updating....."
- Next in thread: Richard B. Johnson: "Re: EXT2 and BadBlock updating....."
- Reply: Richard B. Johnson: "Re: EXT2 and BadBlock updating....."
- Reply: Andre Hedrick: "Re: EXT2 and BadBlock updating....."