In the context of #773035, I am looking for a way to figure out whether a reboot *now* would be likely to cause lengthy fsck routine checks, e.g. due to the maximal mount count or days since last check being reached on ext-filesystems. I'd like to avoid parsing debug2fs or tune2fs output and comparing numbers or timestamps in the text output, like /usr/lib/update-notifier/update-motd-fsck-at-reboot seems to be doing on Ubuntu. Instead, I'd really like to just ask fsck. fsck -A -t ext2,ext3,ext4,… -N is already very helpful showing me which filesystem-specific commands it would run, but each of those is run unconditionally on the filesystem and determines by itself whether a check is needed. There is the -n option, and it does seem that the sought information could be parsed from the output, but invoking fsck -n on a mounted filesystem is quite unreliable and it'd be a hack too. So instead, I envision a call such as: fsck -A -t ext2,ext3,ext4,… -q or fsck -q /dev/mapper/vg-root and it would exit 0 if a routine check was not going to happen, and exit non-zero if a check would now happen (possibly encoding the reason in the exit code). -V output could also be provided. Thanks for your consideration.
reassign 773267 e2fsprogs thanks The mount count fsck is specific to ext2 ( for that matter, it is at this point, a silly anachronism that many people disable.. iirc it is disabled by default these days on ubuntu ) so there is no reason to generalize it to fsck. I'm reassigning to e2fsprogs so they can consider adding something to e2fsck but my guess is they will say to just use tune2fs.
also sprach Phillip Susi <psusi@ubuntu.com> [2014-12-16 15:18 +0100]: No other filesystems have routine checks that could run during startup? I seem to remember XFS had those too… If it's only ext2,3,4, then by all means. But if there are others, then I guess it should be generalised.
For newly created ext2/3/4 file systems, we no longer enable periodic checking by default. Too many people complained, and most file system authors assume that storage devices are perfect. (The fact that they aren't is a different story, but that's the cheap SSD/eMMC device's fault.) Besides, what I recommend that the wise sysadmin set up these days is this: https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/contrib/e2croncheck I've thought about trying to get this packaged up automatically for debian, but I've never had the time, and don't have the debconf-fu to prompt for the e-mail address, which devices should be checked, how big to make the snapshot value, etc. It does require using LVM, but the wise administrator really should be using LVM these days. - Ted
also sprach Theodore Ts'o <tytso@mit.edu> [2014-12-16 17:49 +0100]: I'll still employ those features. Better safe than sorry. And I would have never so much as dreamt about using the words "storage devices" and "perfect" in the same paragraph! ;) Both of these are good developments, but you cannot assume LVM on every machine. Especially embedded systems won't use them, and those will be particularly hurt by e2fsck running unexpectedly after a reboot. And while LVM is not priority:required, you won't be able to install the cronjob automatically anyway. All of this considered, and assuming it won't be hard, are there other reasons against a -q flag to e2fsck, which uses the same logic to print information to stdout or exit() as it uses to determine whether to run a long check? Cheers,
I think there is some expectation mismatch going on here. Aside from the mount count check, e2fsck normally skips the check if the dirty flag is not set. If the FS is currently mounted, then the dirty flag is set, so trying this test at that time would always say there is going to be a long fsck. As a result, the answer to the question "will there be a long fsck on the next boot" depends on whether or not the system will be shutdown cleanly or not, so you really can't ask the question and get a meaningful result. The only thing you can get a meaningful result from is "will the mount count limit be reached on the next boot"?
also sprach Phillip Susi <psusi@ubuntu.com> [2014-12-16 21:49 +0100]: A bit of context: I am intending to analyse the answer to this question as part of the admin's call to /sbin/reboot, so we can assume a clean shutdown indeed. The chance of an unclean reboot between typing /sbin/reboot and the actual reboot should be about as high as the chance of /sbin/reboot being typed 3–5 seconds before those 180 days elapsed, and can in both cases be ignored.
I'm not sure I understand why this would be useful. Suppose the answer is "e2fsck is going to check all of the disks and it's going to take two hours to check your RAID array". Is that going to make a difference to the sysadmin in terms of deciding whether or not to continue? And note that if I add this to e2fsck, the calling program is still going to have to parse /etc/fstab and call e2fsck with some magic option which will do this check. I'm just not sure how generally useful this will be, and it's not clear to me that it's worth the effort. If I did do this, it would probaby be as a standalone program in contrib, and I'm not sure I would package it, simply because I'm not yet convinced how many users would use it, and maintaining it as yet another binary in /usr/bin, and another man page, if it's highly specialized and only one or two users would find it useful, doesn't seem to me to be a good trade off --- espceially since we've already changed the default due to too many users kvetching and whining about the boot-time check. (Me, I use LVM snapshots and checks that don't require that I do a rebooot; this also means I can do them much more frequently. The e2croncheck ***really*** is a the right way to go.) - Ted
also sprach Theodore Ts'o <tytso@mit.edu> [2014-12-17 05:44 +0100]: Yes, I think so. It might make him/her postpone the reboot to the night, rather than to run it during lunch break. fsck -A -T … does this already for us. You've turned off the default parameters, i.e. made them 0 or impossibly large so that routine checks don't run anymore. The fsck code still includes the logic to check whether a routine should be run. Instead of writing a new binary to do this, it seems adding -q to e2fsck would allow you to reuse this logic, would not add another binary anywhere and would only require a tiny change to the manpage. Yes, but I ***really*** doubt that Debian will make LVM required anytime soon.