Blockbusting news, results are in
Jan-Benedict Glaw replied to me:
Quoted 8 lines
Quoted 5 lines
After a few other experiments, I used smartctl to direct the drive to do a long self-test. When it completed, we observed that the drive had self-diagnosed a read failure on the same bad sector number as always, and we observed that the drive did not reallocate the bad block during long self-tests.
Maybe the drive can't remap the block because there's no free space in the remap area available any more...
As previously reported about twice in this thread, the first time I ran "smartctl -a" it reported that the quantities of reallocated sector events and reallocated sector count were both 1, and when I ran it again after the first long self-test, both of these quantities had increased to 2. If there were no room in the remap area, then how did the remaps increase from 1 to 2 while the permanently bad sector remained non-remapped and permanantly bad?
Here's more results. The quantities of reallocated sector events and reallocated sector count have both increased to 3. Meanwhile the permanently bad sector remains permanently bad. I think that there is still room remaining in the remap area.
By this time I think my friends at Toshiba agree that Toshiba's firmware is inadequate, though participants in this LKML thread are about evenly divided on the issue. It seems that Maxtor's firmware is better, though I notice the silence regarding my questions of customer non-service and uncertain warranties (when Maxtor distributed one drive with two incompatible sets of jumpering instructions). And other manufacturers still aren't saying whether their firmware is adequate. It still seems that either Linux must be made to work around known bad blocks or else hard disks and Linux cannot be used together on a computer.
Quoted 3 lines · Norman Diamond
It still seems that either Linux must
be made to work around known bad blocks or else hard disks and Linux cannot be used together on a computer.
That is a bit of a troll. I suspect that 70 - 90 percent of linux installations on a computer are using hard disks. Yet the number of people having the same problem as you doesn't appear to be 100% of those.
Making intentionally inflammatory statements to try and win others to your point of view tends to do exactly the opposite.
If there are enough people experiencing the problem, it gets fixed, at least as far as I can tell. There have been a nunmber of viable ideas proposed in this thread to handle the situation you are talking about, and while none of them are exactly what you proposed, feel free to write code. Baiting comments like the above don't really accomplish anything constructive.
-chuck
Quoted 12 lines · Chuck Campbell
Quoted 3 lines · Norman Diamond
It still seems that either Linux must
be made to work around known bad blocks or else hard disks and Linux cannot be used together on a computer.That is a bit of a troll. I suspect that 70 - 90 percent of linux installations on a computer are using hard disks. Yet the number of people having the same problem as you doesn't appear to be 100% of those.
Making intentionally inflammatory statements to try and win others to your point of view tends to do exactly the opposite.
Quoted 7 lines
If there are enough people experiencing the problem, it gets fixed, at least as far as I can tell. There have been a nunmber of viable ideas proposed in this thread to handle the situation you are talking about, and while none of them are exactly what you proposed, feel free to write code. Baiting comments like the above don't really accomplish anything constructive.
-chuck
I thought both ext2 and ext3 do handle bad-blocks. They just don't make them owned by a "file" because the Unix file-systems don't require dummy directory entries.
If the respondent wants them isolated into a "BADBLOCKS" file, he can make a utility to do that. It's really quite easy because you can raw-read disks under Linux, plus there is already the badblocks program that will locate them.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Quoted 4 lines · Richard B. Johnson
If the respondent wants them isolated into a "BADBLOCKS" file, he can make a utility to do that. It's really quite easy because you can raw-read disks under Linux, plus there is already the
badblocksprogram that will locate them.
Yes, it's trivially easy to figure out that block 193453 on /dev/hdb is bad. It's even not too bad to map that to an offset on /dev/hdb4. Even if you're using LVM or DM to map stuff, it's still attackable. But how do you guarantee that block 193453 gets allocated to your badblocks file and not to some other file that just tried to extend itself by 32K?
Quoted 7 lines · On Tue, 21 Oct 2003 [email protected] wrote:
Quoted 4 lines · Richard B. Johnson
If the respondent wants them isolated into a "BADBLOCKS" file, he can make a utility to do that. It's really quite easy because you can raw-read disks under Linux, plus there is already the
badblocksprogram that will locate them.
Quoted 7 lines
Yes, it's trivially easy to figure out that block 193453 on
/dev/hdbis bad. It's even not too bad to map that to an offset on/dev/hdb4. Even if you're using LVM or DM to map stuff, it's still attackable. But how do you guarantee that block 193453 gets allocated to your badblocks file and not to some other file that just tried to extend itself by 32K?
You repair file-systems when they are not mounted. Also, the source of an old version of e2fsprogs has a "defrag" utility that could be used as a sample of how to create a file that owns the bad blocks you find.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Quoted 7 lines · On Tue, Oct 21, 2003 at 04:21:26PM -0400, [email protected] wrote:
Quoted 4 lines · Richard B. Johnson
If the respondent wants them isolated into a "BADBLOCKS" file, he can make a utility to do that. It's really quite easy because you can raw-read disks under Linux, plus there is already the
badblocksprogram that will locate them.
Quoted 5 lines
Yes, it's trivially easy to figure out that block 193453 on
/dev/hdbis bad. It's even not too bad to map that to an offset on/dev/hdb4. Even if you're using LVM or DM to map stuff, it's still attackable. But how do you guarantee that block 193453 gets allocated to your badblocks file and not to some other file that just tried to extend itself by 32K?
Read the e2fsck man page, and pay attention to the -c, -l, and -L options....
- Ted
Quoted 2 lines · Theodore Ts'o
Read the e2fsck man page, and pay attention to the -c, -l, and -L options....
Yes, I knew this was doable if the filesystem was unmounted - the fun is of course that if you get a bad block in /usr or someplace similar, it would REALLY be nice to be able to do something about it without taking it offline..
The cynic in me says that if I have to take it down to flag a bad block, I'm going to use the downtime to just replace the *bleep*ing thing with something more acquainted with the concept of block relocation - if it didn't relocate it, either the relocation sectors are used up or the drive has pessimal microcode, both of which are bad news.
I admit I haven't cooked up a test filesystem and actually checked what happens if you feed the -l flag a block that's already in a file (presumably it deallocates it from the inode and leaves a sparse hole) or a block that contains inodes or a superblock copy...
Quoted 3 lines · On Tue, Oct 21, 2003 at 10:32:34PM -0400, [email protected] wrote:
Yes, I knew this was doable if the filesystem was unmounted - the fun is of course that if you get a bad block in /usr or someplace similar, it would REALLY be nice to be able to do something about it without taking it offline..
Agreed, it wouldn't be that hard to add some kernel code to do this on-line, at least if the block isn't already allocated. If the block is already allocated, there would need to have to be some userspace help to find which file the block actually belongs to, so the block could be substituted out and the user appropriatly warned.
Quoted 4 lines
I admit I haven't cooked up a test filesystem and actually checked what happens if you feed the -l flag a block that's already in a file (presumably it deallocates it from the inode and leaves a sparse hole) or a block that contains inodes or a superblock copy...
It gets treated as a block that has been claimed by two inodes (which it is; the original inode and the bad block inode). E2fsck gives the user the option of (a) allocating a new block so that the file gets replacement block with whatever data could be copied from the bad block, or (b) if the user declines the first option, e2fsck next gives the user the option of deleting the file containing bad block.
- Ted