Package: e2fsprogs
Version: 1.47.0-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: [email protected]
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.
All the best,
Christoph
[1] proc_apm_show in drivers/char/apm-emulation.c
Example output: "1.13 1.2 0x02 0xff 0xff 0xff -1% -1 ?"
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.62 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages e2fsprogs depends on:
ii libblkid1 2.39.2-5
ii libc6 2.37-12
ii libcom-err2 1.47.0-2+b1
ii libext2fs2 1.47.0-2+b1
ii libss2 1.47.0-2+b1
ii libuuid1 2.39.2-5
ii logsave 1.47.0-2+b1
Versions of packages e2fsprogs recommends:
pn e2fsprogs-l10n <none>
Versions of packages e2fsprogs suggests:
ii e2fsck-static 1.47.0-2+b1
pn fuse2fs <none>
pn gpart <none>
ii parted 3.6-3
-- Configuration Files:
/etc/mke2fs.conf changed [not included]
-- no debconf information
Acknowledgement sent
to "Theodore Ts'o" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Theodore Y. Ts'o <[email protected]>.
(Sun, 12 Nov 2023 06:09:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1055808: fsck at boot always skipped due to APM_EMULATION
kernel option
Date: Sun, 12 Nov 2023 01:04:24 -0500
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: [email protected]
>
> 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
Acknowledgement sent
to hristoph Biedl <[email protected]>:
Extra info received and forwarded to list. Copy sent to Theodore Y. Ts'o <[email protected]>.
(Tue, 28 Nov 2023 12:12:02 GMT) (full text, mbox, link).
Theodore Ts'o wrote...
> 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.
My perception was otherwise but I shouldn't argue without solid proof.
And yes, I am enabling periodic fsck checks, having experienced
corrupted file systems a few times in the past (rather caused by failure
in the underlying block device than by ext4 itself). Migrating to
e2scrub still is something to consider where possible.
Still, I find an "on battery" message disturbing if there isn't any. So,
if I do (some output stripped):
# fallocate --length 128M /tmp/blob
# mkfs.ext4 /tmp/blob
# tune2fs -c 36 -C 35 /tmp/blob
# cat /proc/apm
1.13 1.2 0x02 0xff 0xff 0xff -1% -1 ?
# e2fsck 1.47.2 (5-Feb-2023)
/tmp/blob: clean, 11/32768 files, 13883/131072 blocks (check deferred; on battery)
^^^^^^^^^^
That's why I'd prefer to derive "on battery" from that APM line only if
and only if APM's "AC line status" is "off-line", and otherwise not. But
I'll leave that to you to decide.
All the best,
Christoph
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.