On Sat, Nov 11, 2023 at 10:22:21PM +0100, Christoph Biedl wrote:
> Package: e2fsprogs
> Version: 1.47.0-2+b1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
>
> Greetings,
>
> Summary: If the APM_EMULATION kernel option is enabled (and built-in),
> fsck during boot may be skipped all the time.
>
> Longer story: One day I noticed some virtual machines have huge "mount
> count" values, and "next check after" at a date far in the past. (I have
> enable_periodic_fsck set.) After some research I learned I had (by
> accident) enabled the APM_EMULATION kernel option. So /proc/apm exists
> but has more or less static content[1]. The important part is is_on_batt
> in e2fsck/unix.c which reads the AC status as 0xff ("unknown"), and
> effectively treats this as "on battery".
>
> So may I ask you to re-visit that check in that regard? I'll disable
> that option anyway, other people still might get into trouble because
> of that.
This was behaviour that was requested per Debian bug #205177[1], and
note that it doesn't skip the checks forever. It just doubles the
check interval (so if check interval is 14 days, it will make it be 28
days), and if the max_mount_count was 20, it will not wait until the
40th mount. So it's not "always skipped"; it's rather deferred.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205177
I'll also note that for modern file systems, mke2fs disables periodic
checks entirely, by setting check interval to zero and the max mount
count to -1. For example from the output of "dumpe2fs -h" run on my
laptop's root file system:
Filesystem created: Sat Dec 19 17:28:55 2020
Last mount time: Wed Nov 1 13:44:11 2023
Last write time: Wed Nov 1 13:44:09 2023
Mount count: 58
Maximum mount count: -1
Last checked: Sun Aug 15 23:12:00 2021
Check interval: 0 (<none>)
So yeah, there is a large mount count, and it hasn't been checked
since August 2021. But that has nothing to do with is_on_batt()
check. Are you in fact explicitly enabling periodic fsck checks? If
this is a cloud image, I would expect the file systems to be new
enough that it should be getting the new mke2fs defaults.
Basically, we assume that modern hardware is more robust, and we're no
longer doing periodic fsck checks on general principles. This was
more because we didn't trust crappy PC hardware many decades ago. But
as file systems have gotten bigger, and fsck times started taking
longer and longer, we dispensed with periodic checks entirely.
These days if you are paranoid enough to want to do periodic checks,
the better solution is to rely on e2scrub (assuming that your are
using LVM).
Cheers,
- Ted
