Finger info for relnev@icculus.org...


After several months, an ext2 partition was discovered to be two sectors
too large, thanks to mysterious program failures and lengthy e2fsck
sessions.  I do not know if I either made the mistake or the drive
geometry as the kernel saw it had somehow mysteriously changed. 
Whatever the reason, the error was never discovered until now, not even
e2fsck (and e2fsck -c) would complain.  That seriously sucks.

When the problem finally surfaced, it appeared in the guise of bad
blocks.  "Attempt to read block from filesystem resulted in short read"
Oh great, the drive's dying.  3903 badblocks result.

After looking at the dmesg output and seeing the sector id not found
errors, it started to become clear that something else was wrong. 
Finally I realized that the partition was way too big, and the errors
were caused by reading non-existent sectors.  Now the problem was to
figure out how to fix this mess.

Luckily, I rarely have had any major disk problems.  Unfortunately, it
makes me unprepared for situations like these.  parted and cfdisk didn't
want to touch the partition; how useless.  fdisk actually prints a
warning message when verifying the partition, why did I miss this when
creating the partitions?  resize2fs didn't like receiving errors from
reading the nonexistent blocks.  So, I boot up tomsrtbt and end up using
fdisk to delete the old partition and create a new but smaller one. 
Then, I keep trying resize2fs, but it still won't complete.  Turning on
debug output reveals that it is trying to move nonexistent blocks, so I
have to use debugfs to free those blocks.  debugfs didn't want to use
the count value, so I had to manually specify all 3903 freebs (generated
by a script, of course).  Now resize2fs is happy and e2fsck isn't
reporting any errors.
    

When this .plan was written: 2002-12-17 04:23:20
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.24
Stick it in the camel and go.