i recently upgraded the linux kernel on an old workhorse of a machine ("grunt"). i got grunt in a yard sale back in 2000 for ~$35, and he has worked splendidly and untiringly since then, even moving across the country with me.

sometime between 1 or 2 years ago, i put a large extra disk into grunt, and i've been using that disk as a massive filestore since then. (it's not so massive now, of course, because disks have gotten larger, but...)

anyhow, grunt is running debian linux ("sarge"), which is normally incredibly stable and robust. I upgraded the kernel recently because there was a raft of security updates recently released for sarge. patching is good computer hygiene, and this particular kernel upgrade was probably a bit overdue. However, this was grunt's first reboot in over 6 months, and when he came back up, his initscripts wanted to fsck the huge disk. This fsck run took well over 10 minutes: the ATA bus is an old, slow one, and the disk is massive. It didn't help things that i panicked in the middle of it and tried hard-resetting the machine because i couldn't tell what was going on. This just caused the fsck to restart from the beginning again, of course.

i would have been better served by checking the last fsck date on the large volume before rebooting, and (had i noticed that it was due for a new fsck) unmounting it and fscking it before the reboot when i still had control over the system and could tell what was going on.

So the lesson for me here is: before any scheduled reboot (especially one involving a change of kernels), get a sense of which volumes will want an fsck. If those volumes are extremely large, consider trying to fsck them *before* the reboot, so that you'll be able to tell the difference between a truly frozen, screwed up kernel, and a machine that's simply churning through 200GB of data on a bus that wasn't designed to consider that level of use.