On Mon, 26 Mar 2012, Craig Sanders wrote:
On Mon, Mar 26, 2012 at 03:01:18PM +1100, Tim Connors wrote:
[ ... xfs_repair ... ]
Now if only there was a fsck.xfs and regular checks every ~20 mounts.
alternatively, and with 50% less facetiousness, you can even make ext[234] filesystems behave in a non-annoying manner:
tune2fs -i 0 -c 0 /dev/ext[234]partition
But didn't you just demonstrate why regular checks are a Good Idea? Bad shit sometimes happens, and better to know about it than silently ignore it. Personally, I use Ted Tso's trick to taking LVM snapshots and 'e2fsck -fy'ing the snapshot. If it succeeds, tune2fs the original device to reset the counter, if it fails, send an email to the admin to schedule a reboot and tune2fs the device to say it's been mounted a bajillion times. But a recent update to lvm and/or kernel no longer seems to properly quiesce the filesystem[1], so I get these: e2fsck 1.42 (29-Nov-2011) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong (27450610, counted=27450649). Fix? yes Free inodes count wrong (19841641, counted=19841642). Fix? yes (I do a preen with e2fsck -p just to get rid of the /dev/gamow/2012-03-25+04.44.28-root-snapshot: Clearing orphaned inode 1156235 (uid=0, gid=0, mode=0100644, size=161848) warnings that always happened after a snapshot. The inode counts requiring a fix never used to happen though.) [1] I'd love to submit a bug report, but I don't know which part has broken, and I fear I'm doing things non standard enough (even with Tso's blessing) that no one will care enough to hunt for the bug. Plus, my system is a bastardised sid/testing/stable machine, so it's all probably my fault, even though I think I took care to make sure that lvm/e2utils/kernel/libraries were taken from the same branch at the same time. -- Tim Connors