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.