Blockbusting news, results get worse
It gets worse. First, to recap previous results:
1. The drive reported a permanent error on read, refused to reallocate the bad sector, and Linux logged the error but refused to remove the block from the Reiser file system. (Different people have different opinions about whether various parts of this behavior are acceptable, but anyway this was one of the observed results.)
2. The drive reported a permanent error on write, refused to reallocate the bad sector, and Linux logged the error but refused to remove the block from the Reiser file system. (I'm not sure if different people have different opinions about whether various parts of this behavior are acceptable. This was a write, good data were known at the time, but subsequently good data would never be retrievable from the file.)
3. The drive reported a permanent read error during a S.M.A.R.T. long self-test and refused to reallocate the bad sector. (I think different people have different opinions about the acceptability of this too.)
Well, here's news.
4. When writing ZEROES to the bad sector, the drive reports SUCCESS. But it lies. Subsequent attempts to read still fail. Subsequent writing of zeroes appears to succeed again. Subsequent attempts to read still fail.
I swear, I want that block out of the file system. Even if the writing of zeroes really succeeded, I would not be satisfied with the continued use of that block. I really want the drive to reallocate it, but Toshiba's firmware is unsafe to drive at any speed. So I really want the file system to exclude that block.
Some participants in this discussion have said that ext2fs can exclude bad blocks in a way that ReiserFS doesn't, though ReiserFS probably will in the future. But to the best of my understanding, ext2fs can detect and exclude bad blocks at the time of formatting and at the time of a destructive read-write test. I have not seen news from anyone about whether ext2fs will remove a detected permanent bad block from an existing mounted filesystem at the time that the error is detected during normal operations. It is 99% necessary to do so (leaving 1% for audio visual applications where it's more important to play a movie erroneously at proper speed than to attempt recovery).
By the way, one participant in this thread recommended not buying disk drives from bargain basement outlets. OK, yesterday I inquired at Bic Camera, which might be one of the biggest two retailers of computers and parts nationwide, but might not be because they don't have many stores outside of the Tokyo area. At least they're surely one of the two biggest in Tokyo. They said that they warranty Toshiba disk drives for 1 year. So if a customer buys a Toshiba disk drive with firmware that was defective on the day of purchase and defective on the dates of design and manufacture, but if the customer doesn't detect the defective firmware until 366 days later, the customer still gets shafted.
I still have to say, we can't fix Toshiba, and we can avoid Toshiba, but meanwhile we can fix Linux. Among other manufacturers, only Maxtor has said that their firmware isn't broken in this way, but Maxtor doesn't make drives for notebooks. Just how many manufacturers of disk drives are we going to avoid, or can we hope that Linux will be made to compensate for their defects?
Well, in a future weekend, I will try to see if ext2fs really takes action on permanently bad blocks that are detected during normal operations on a mounted partition.
Quoted 6 lines
4. When writing ZEROES to the bad sector, the drive reports SUCCESS. But it lies. Subsequent attempts to read still fail. Subsequent writing of zeroes appears to succeed again. Subsequent attempts to read still fail.
I still have to say, we can't fix Toshiba, and we can avoid Toshiba, but meanwhile we can fix Linux.
How do you suggest we 'fix' 4, above, other than to flush the cache and verify each time a full sector of zeros is written to the disk?
John.
Hi!
Quoted 9 lines
Quoted 6 lines
4. When writing ZEROES to the bad sector, the drive reports SUCCESS. But it lies. Subsequent attempts to read still fail. Subsequent writing of zeroes appears to succeed again. Subsequent attempts to read still fail.
I still have to say, we can't fix Toshiba, and we can avoid Toshiba, but meanwhile we can fix Linux.
How do you suggest we 'fix' 4, above, other than to flush the cache and verify each time a full sector of zeros is written to the disk?
Well,
if (drive_is_toshiba())
panic("Forward harddrive to nearest trashcan.\n");during bootup?
Reporting sucess when it is not, is, umm, bad.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
John Bradford pretended to reply to me:
Quoted 10 lines
Quoted 7 lines
4. When writing ZEROES to the bad sector, the drive reports SUCCESS. But it lies. Subsequent attempts to read still fail. Subsequent writing of zeroes appears to succeed again. Subsequent attempts to read still fail.
I still have to say, we can't fix Toshiba, and we can avoid Toshiba, but meanwhile we can fix Linux.
How do you suggest we 'fix' 4, above, other than to flush the cache and verify each time a full sector of zeros is written to the disk?
Number 4 cannot be fixed by Linux. Why do you pervert my writing?
The refusal to remove a known defective block from ordinary use in the file system can be fixed. How many times does this need to be said? Why do you pretend that this is not what I have been saying in this entire thread?
If I understand Hans Reiser's message correctly, this fix has indeed been made in ReiserFS version 4. I thank Mr. Reiser. (By the way, I volunteer about one day each weekend for testing, and I am hardly in a position to contribute funds. Please let's not beggar each other.)
By the way some participants in this thread have argued that the block should not be replaced by zeroes or random garbage without notice. I fully agree. The block should be replaced by zeroes or random garbage WITH notice. From the point of view of logging it in the system log, it is enough to log it once, it doesn't have to be logged over and over again.
Quoted 1 line
From the point of view of informing the user whose program is running, the
dd command does an excellent job, but some unknown program was remaining silent when I/O errors were originally detected and logged. I still think it is better to get that block out of the file system so that when that file is rewritten or when other new files get created or extended then they won't try to reuse that block. But I've said this enough too. I guess it's time to stop beating this dead horse. But anyway Mr. Reiser understood, and I am glad, and I thank him.
Hi!
Quoted 6 lines
By the way some participants in this thread have argued that the block should not be replaced by zeroes or random garbage without notice. I fully agree. The block should be replaced by zeroes or random garbage WITH notice. From the point of view of logging it in the system log, it is enough to log it once, it doesn't have to be logged over and over again.
It *does* have to be logged over and over. How does disk know system did not crash between it returning an error and syslog message getting written?
Pavel
PS: Okay, we should end this thread here.
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 5 lines · Norman Diamond
. Please let's not beggar each other.)
I have been beggared quite without your help.;-)
Signature · 1 line
Hans
Quoted 4 lines · Norman Diamond
By the way some participants in this thread have argued that the block should not be replaced by zeroes or random garbage without notice. I fully agree. The block should be replaced by zeroes or random garbage WITH notice.
Right. The correct way of sending such a notice is returning I/O error on read. It's standard and applications support it for years (of course we can - and currently do - log the error as well).
Quoted 2 lines
From the point of view of logging it in the system log, it is
enough to log it once, it doesn't have to be logged over and over again.
Storing a log entry in system log doesn't tell applications there is a problem. It's simply unacceptable.
Relocating on write (at filesystem level) - sure, it would be helpful (possibly as a compile-time option - most IDE drives and things like RAM disks don't need it).
Signature · 1 line
Krzysztof Halasa, B*FH