Hi Adam, Sorry for the belated reply, I didn't receive this email for some reason until I bts show --mbox to update it a notice I filed a MR.
On Sat, Jun 08, 2019 at 03:57:13PM +0200, Adam Borowski wrote: > Control: severity -1 important > > > Severity: serious > > Justification: Debian Policy violation > > > /bin/mkfs.btrfs and /bin/fsck.btrfs are Policy and FHS violations. > > I don't believe this is in any way RC -- for Buster nor likely any future > release. There's no functional lossage, AFAIK. > Yeah, it's in the class of legalistic RCs. Standards aren't standards if nobody follows them... Of course we have the freedom to do whatever we want though ;-) > fsck probably should indeed be moved away from /bin -- it's a legacy > atavistic thing that's not of much use to users. Filesystems of old > suffered corruption on every unexpected power loss and thus required automated > fsck. That's not the case during current millenium. Among mainstream > filesystems, only ext4 still ships real fsck (mostly for historic reasons), > I think jfs has it trigger log replay; the rest (btrfs, xfs, f2fs, ...) ship > just a stub that does nothing. There are actual repair tools but those > shouldn't generally be run other than as a hail mary effort; regular checks > are supposed to use online scrub instead, without downtime. > Have you seen Qu Wenruo's view on this yet? tldr; btrfs check --readonly after unclean shutdown, to catch early warning signs. https://www.spinics.net/lists/linux-btrfs/msg90485.html Yeah, I agree, that's not supposed to be necessary with a next-gen fs :-( But Qu recommends it... It's easy to enable this on an opt-in basis with something like a /forcefsck that is created when the fs is mounted and removed during shutdown, but I imagine autodetecting and deduplicating the list of mount points is problematic in cases where there are many "-o subvol=foo" mounts and where subvolid=5 isn't mounted. eg: default to nil, don't do anything, and if users want this upstream-recommended behaviour then they can configure a list of mounts to check. > Moving that stub has been requested in #798072. > Thanks for fixing it! > mkfs on the other hand is widely used by non-root users these days. On raw > metal, you generally mkfs once per hardware replacement, while VMs or board > images get created often. > > Thus, I'd rather ask for Policy change than to alter the package. > Btrfs-progs is the only package that has this issue... Why is it a valid special snowflake? <- A question the Policy team will ask. > This means, I don't consider the bug to be serious. > I agree that it's "policy serious" and not "practical serious". Cheers, Nicholas
signature.asc
Description: PGP signature
