Re: The sixth field (fs_passno) should be zero
Dimitri John Ledkov: > Most filesystems support destructive operations,
with a goal to recover data via some-sort check/repair functionality
e.g. btrfs check/rescue, xfs_repair etc. > Some filesystems also require
periodic maintenance calls, e.g. something like the `harmless' fsck on
each mount. > Some filesystems support both destructive recovery and
periodic maintainance via fsck interface. > However most filesystems in
use today, have their own native tooling for destructive recovery and
don't need periodic maintenance calls. If you'd described this in terms
of "preen mode", I think that it would have been clearer to other people
what you are getting at. Dimitri John Ledkov: > At the moment stable
debian releases configure (well partman, or partman-$foo) mountpoints in
/etc/fstab with passno set to 1 or 2, which means run "fsck" in a
priority order. > This leads to a following chain of events on
filesystems that do not require periodic maintenance and only have their
own destructive recovery tooling:
(... "that have no-op for preen mode and only have a full interactive,
non-preen, mode of checking" ...)
Dimitri John Ledkov: > - debian-install sets passno to 1|2 > -
initramfs-tools includes fsck.$foo scripts > - on each boot these are
called > - $foo-progs packages ship these fsck.$foo scripts > - and said
fsck.$foo scripts do nothing > > This is currently the case for xfs and
btrfs, which imho is silly. > > I'm proposing to do following, for
filesystems that require no periodic maintainance:
(... "whose fsck tools do nothing for boot-time 'preening' anyway"... )
Dimitri John Ledkov: > - d-i to set passno to 0 > - initramfs-tools to
not include fsck.$foo tools for passno=0 mountpoints > - not spend time
on each boot, forking shell scripts that do nothing > - $foo-progs
packages to stop shipping dummy wrapper scripts fsck.$foo > - on upgrade
force set passno to zero for filesystems in question > - $foo-progs
packages to still ship initramfs-tools hooks that include/update
initramfs with latest disaster recovery tooling (e.g. btrfs
check/rescue, xfs_repair, e2fsck etc.)
The main thing that this is gaining you is the second bullet point: not
spending tine forking the fsck.btrfs and xfs_fsck shell scripts that
print messages and exit 0. Whether that's a major objective is
debateable, but on the presumption that it is you're spending a lot of
effort there for something that is achieved more simply.
Don't change anything with the installer or upgrade, and just replace
the no-op fsck.$fstype scripts with symbolic links to /bin/true .
systemd has an undocumented mechanism that checks for that, and when it
is detected as the case both makes systemd-fsck do nothing and doesn't
bring in the systemd-fsck@.service for the volume in the first place.
*
http://lists.freedesktop.org/archives/systemd-devel/2014-June/020714.html *
http://lists.freedesktop.org/archives/systemd-devel/2014-June/020737.html
Reply to: