Re: The sixth field (fs_passno) should be zero
On 24 November 2015 at 03:12, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> On Tue, 2015-11-24 at 02:51 +0000, Dimitri John Ledkov wrote:
>> This is currently the case for xfs and btrfs, which imho is silly.
> Well sooner or later, btrfs check is declared stable and then I think
> we do want to have regular checks (though don't know whether this is
> upstream's recommendation).
>
nope, this is not the tool you are looking for.
btrfs check is a destructive tool, that can attempt repairing btrfs
filesystem. it should not be run automatically, nor non-interractive,
nor on each boot.
also it can affect other mountpoints, if one is mounting multiple
subvolumes or uses raid, which is completely outside of scope that
fsck(8) interface can handle.
ditto xfs_repair.
> In fact, btrfs seems to be quite useful already these days...
>
>
>> I'm proposing to do following, for filesystems that require no
>> periodic maintainance:
>
>> - initramfs-tools to not include fsck.$foo tools for passno=0
>> mountpoints
> IMHO, initramfs hooks should generally the tree of stacked block
> devices/containters/fs (e.g. MD, dmcrypt, lvm, etc.) for the necessary
> devices (typically root and resume?) and only include those tools
> actually required.
>
my comment is specifically about fsck hook shipped inside the
initramfs-tools package, rather than generic hooks, that variety of
our packages rightfully ship.
>
>> - on upgrade force set passno to zero for filesystems in question
> uhm... you mean changing around in user's /etc/fstab? Sounds not
> appealing.
>
yes. specifically resetting in btrfs lines, of filesystems that are in
fact btrfs, passno field to zero.
>> Feedback? Questions? Concerns?
> I'm a bit sceptic that there is really something like a fs that
> requires no periodic maintenance...
> I've already had some issues found with btrfs check, even though one of
> them proved to be a bug in btrfs check itself (which is right now being
> hunted down by one of the developers).
>
> It's already some years ago I've used XFS, but then I regularly ran
> xfs_repair in scan-mode... and I think I remember that issues were
> found, which weren't during running system.
> But a lot has happened to XFS since then.
>
>
> I'd rather say, ask usptream whether they'd suggest to run btrfs check
> on boot (in non-destructive mode)
>
they do not, instead they ship fsck.btrfs shell script, that exits
zero and does nothing. Ditto xfs.
To specifically to passify systems which demand running periodic fsck,
when none is needed nor supported for these filesystems.
https://sources.debian.net/src/btrfs-tools/4.3-1/fsck.btrfs/#L39
https://sources.debian.net/src/xfsprogs/4.2.0/fsck/xfs_fsck.sh/#L24
--
Regards,
Dimitri.
Reply to: