Why force fsck on boot? Why not on shutdown?

[parsim]

Once every few weeks, I get a message like:

[codergeek42]

Fwiw it's worth you can disable that (at least I know you can with ext2/3 systems, not sure how with other FSes). If you're using an ex2/3 FS, tune2fs will help you with this:

[parsim]

Thanks -- I did notice that, but the man page for the -i option in tune2fs says:

[rhill]

considering fsck is generally used to fix problems caused by improper shutdowns (ie. powering down before the disk has a chance to save any write-cached data and unmount) doing it at startup makes the most sense. it's not the only purpose it has of course, but it's the most common. if fsck was only run at shutdown, and you had, say, a power outage, you could be mounting a corrupted filesystem on your next boot. that would be a Bad Thing(c).

the scheduled fscks probably wouldn't be to bad to skip. they're not critical, just kind of a periodic check to make sure stuff is in order. if fsck has a reason to suspect something is wrong with the disk, it'll run regardless of schedule. so i don't think it would be a huge issue if you did a 'tune2fs -i 0 /dev/hda3' and then just added fsck to '/etc/conf.d/local.stop'. make sure you have 'local' set in your init by doing an 'rc-update show' if you decide to do this. it'll run everytime you shut down, but maybe checking the /etc/init.d/checkfs and checkroot scripts might have some leads on how to get around that.

you could also consider using reiser on your root partition. even when it does need to reiserfsck, it takes like a second to do.

--de.

[apmurray]

Actually I am pretty sure this is set via fstab with the last number at the end of a line for a device ie:

[parsim]

Thanks, that makes sense... clearly fsck needs to happen on powerup following a shutdown failure. Thanks also for the suggestion on a workaround.

Perhaps if people will be using ReiserFS in the future, this won't be such an issue. And if you're running an always-on server, I guess it doesn't matter one way or the other. But for home users, having your desktop be completely unavailable for several minutes, as it is during an fsck, at the very point you sit down to start work, seems bizarre. It's incredibly user-unfriendly and I wonder if there's a good reason for it.

[codergeek42]

[parsim]

Oh, I read this as suggesting fsck was faster with ResierFS. Maybe I misinterpreted.

[codergeek42]

[parsim]

I hit the magic 23rd boot again today, which reminded me to keep on with this issue.

I think this is crazy: last night when I shut down, my computer was off in about 10 seconds. This morning, when I sit down to work, it took 7 minutes to boot. I just don't think it's acceptable for a desktop OS to regularly take that long to boot.

dirtyepic posted above a possible way to get scheduled fsck checks to happen on (every) powerdown rather than boot, but what I really want to know is why this isn't the default behavior. Why are we making the majority of Linux users sit through fsck checks on every Xth boot, when they need their computer, and not on every Xth shutdown, when they don't? Is there a dev I could write to?

[jbpros]

This has been said: fsck'ing at boot permits bad shutdowns recovery.

You may want to try setting interval-based checks instead of both interval and mounts count:

tune2fs -c 0 -i 14d /dev/hda1

Will make the system check the partition hda1 every 14 days, no matter the mounts count. This is a good idea on a desktop system.

[parsim]

Thanks, but I do appreciate that. My issue is that given:

(a) scheduled fscks have nothing to do with crash-recovery fscks
(b) scheduled fscks are a good idea

why:

(c) scheduled fscks occur during boot and not shutdown

[Archangel1]

How about (d): If fsck is annoying you, why are you still using ext2?
Isn't this one of the biggest reasons to go with a journaled filesystem?

But if you want an answer to (c), it's pretty simple once you engage your brain muscle: fsck is run to check the filesystem for corruption. If the filesystem is corrupted, the system may not boot or may boot improperly.
Now if your fs corrupts, and it locks up halfway through boot, you're not gonna be too happy about fsck running at shutdown are you?

[parsim]

[jbpros]

[feld]

If you fsck on shutdown, won't this prevent an improper shutdown? So then you'd only need to fsck on boot if somehow u powered off instead of shutting down?

I think this is the goal that the author is trying to reach, and i think it makes perfect sense.


-Feld
_________________
< bmg505> I think the first line in reiserfsck is

if (random(65535)< 65500) { hose(partition); for (i=0;i<100000000;i++) print_crap(); }

[vonhelmet]

Not acceptable for a desktop OS to take that long to boot? Plenty of people put up with worse from Windows 98 when it decides it needs to scandisk every single boot.

As has been mentioned, fsck is normally used to recover from an unclean shutdown i.e. a power failure, so you can't always guarantee that it will run when a PC is shut down. It makes more sense to do it at boot in this case, because this is the time when it is most likely to need it.

If you don't like it, then disable the automatic fsck-ing, I think you can do it with the numbers at the end of the lines in fstab. If you want to get it to fsck on shutdown then create an init script that does nothing when it starts and fsck's when it stops.
_________________
My blog
nvtuner software - enhance your AGP Geforce 6800 or 6200!

[parsim]

[chunderbunny]

I think the reason that fsck runs at boot and not at shutdown is that people expect it to behave like that. If fsck ran at shutdown people might wonder why their computer was taking so long to power down and just hit the power button.

Similarly if a scheduled fsck does find a problem then you want the user to be around so that they can read and respond to any error messages that might pop up. If fsck had run on shutdown then the user is likely to have left by the time fsck completes (and when they come back they'll probably just see a blank screen and hit the reset switch.)

[parsim]

[Jengu]

Solution: Switch to ReiserFS.

Rock solid stable for me and I don't have this problem (gentoo-dev-sources).