On Sun, 4 Sept 2022 at 22:15, Mike <deb...@norgie.net> wrote:
> Thanks for the very detailed description. This was just what I was
> after. I'd kind of figured a few things, that it likely needed some
> kind of switch to fsck to produce output and likely systemd was either
> not passing that flag or swallowing the output. I've never delved into
> how disks get fscked on boot, either with systemd or sysv, so I wasn't
> really sure where to start looking.
>
> Your explanation was very helpful and I think also the last point was a
> good one. I've converted the remaining ext3 filesystems to ext4 and
> will see how that goes.
Yes, I feel confident that will give you a huge benefit. You can test it,
see below.
I spent a bit more time looking at this and I am confident now about the
conclusions I have reached.
My previous message was "thinking out load" and somewhat inconclusive, the
contents of this message are more useful.
I have been curious in the past about how all this works, so I had an
interest in looking into it, and am happy to share the results.
1) At boot, the filesystems which have 1 in the 'passno' (sixth) field of
/etc/fstab are checked by /sbin/fsck in the initrd.
I believe systemd is irrelevant, because it is not running at that time.
2) After systemd starts, as explained by 'man 8 systemd-fsck', systemd only
checks the root filesystem if that was not already done by the initrd.
Having systemd check the root file system is something that we want to
avoid, because it would need to unmount it.
When running, systemd also checks the filesystems which have values of
2 or higher in the 'passno' field of etc/fstab, because these are not
checked by the initrd processes.
3) The command 'fsck' works on many filesystems. It is provided by the
'util-linux' package.
In the case of ext2/3/4 filesystems, 'fsck' invokes 'e2fsck' also known
as 'fsck.ext4' to do the work. Those are provided by the 'e2fsprogs'
package.
4) systemd-fsck also uses 'e2fsck' to do the work on ext2/3/4 systems.
5) Not important, but the '-C' argument of fsck and e2fsck are slightly
different.
Giving '-C' to fsck causes it to invoke e2fsck with '-C0'.
Evidence:
# fsck -C -N /dev/sda1
fsck from util-linux 2.36.1
[/usr/sbin/fsck.ext4 (1) -- /mnt/Z] fsck.ext4 -C0 /dev/sda1
#
'-N' invokes a "dry-run", which just prints the command that fsck
passes to its helper program, instead of executing it
Note that e2fsck and fsck.ext4 are the same program.
6) e2fsck is capable of checking multiple filesystems at the same time, for
faster completion when there are multiple drives with the same number in
the 'passno' field of /etc/fstab.
But, as noted by David Wright, e2fsck is only capable of displaying one
progress bar at a time.
7) Looking at the source of fsck
https://sources.debian.org/src/e2fsprogs/1.46.5-2/e2fsck/unix.c
around line 445 is interesting.
It confirms that when fsck gives output like this, often seen at boot:
<device>: clean, 123/456 files, 789/1011 blocks
that the keyword "clean" is fsck telling us "I looked briefly at the
<device> and I decided that it did not need to be scanned".
The code shows tht when this occurs, no progress bar is displayed.
A progress bar is only displayed when fsck actually scans the device.
8) e2fsck can be forced to scan a device by giving it the '-f' option. This
will be done by the initrd code if 'forcefsck' is specified on the
kernel boot command. That is quite an easy test for anyone to do.
9) This kernel parameter 'forcefsck' is detected by
/usr/share/initramfs-tools/init
and slightly modified before being passed to the _checkfs_once()
function in
/usr/share/initramfs-tools/functions
10) I have confirmed that adding 'forcefsck' does cause a progress bar to
be displayed. I tested here on Debian 10 i386 because I needed a slow
machine to see it, because ext4 checking is so fast.
11) I also confirmed that the fsck progress bar is displayed even if
'quiet' is also specified on the kernel command line.
