The sixth field (fs_passno) should be zero
Hello,
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.
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:
- d-i 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:
- 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.)
For the time being this is the plan that I'm hoping to implement for
btrfs on debian. But imho this also applies to xfs. If there are other
filesystems above plan is appropriate, please let me know. (f2fs comes
to mind, but i'm not sure about it)
Feedback? Questions? Concerns?
--
Regards,
Dimitri.
Reply to: