Bug#1006553: btrfs-progs: integration with util-linux fsck

2022-03-07 Thread Adam Borowski
On Thu, Mar 03, 2022 at 07:47:37AM +0200, Martin-Éric Racine wrote:
> On Thu, Mar 3, 2022 at 5:49 AM Adam Borowski  wrote:
> >
> > On Sun, Feb 27, 2022 at 08:32:17PM +0200, Martin-Éric Racine wrote:
> > > As per the enclosed screenshot, btrfs-progs splatters its filesystem
> > > checking message all over the place.  It would be desirable to integrate
> > > it with the util-linux fsck run that follows.

> > btrfs, like all modern filesystems except for ext4, doesn't run fsck at
> > mount time at all. [...]

> It would be a good idea to actually read the bug report before replying.
> 
> Your reply doesn't address the issue AT ALL. It addresses an entirely
> different matter.

... but there's no filesystem checking here.  So what do you suggest
integrating with?

The only message related to btrfs on your screenshot is "Scanning for Btrfs
filesystems", which does nothing fsck related.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy'
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄



Bug#1006553: btrfs-progs: integration with util-linux fsck

2022-03-02 Thread Martin-Éric Racine
On Thu, Mar 3, 2022 at 5:49 AM Adam Borowski  wrote:
>
> On Sun, Feb 27, 2022 at 08:32:17PM +0200, Martin-Éric Racine wrote:
> > Package: btrfs-progs
> > Version: 5.15.1-1
> > Severity: important
>
> > As per the enclosed screenshot, btrfs-progs splatters its filesystem
> > checking message all over the place.  It would be desirable to integrate
> > it with the util-linux fsck run that follows.
>
> btrfs, like all modern filesystems except for ext4, doesn't run fsck at
> mount time at all.  And the reason ext4 does stopped make sense around the
> turn of the millenium, when every unsafe shutdown caused possible filesystem
> corruption, often catastrophic.  Such automated fsck is a throwback to the
> ext2/ext/sysvfs times when it was a hail mary attempt to fix such damage.
>
> As btrfs devs believe that all regular checks are supposed to be done
> online, on a mounted filesystem, fsck.btrfs is not even a primary recovery
> tool, and as thus there's even less point in running fsck at mount time.
>
> Thus, I'm not going to add any such checks, sorry.

It would be a good idea to actually read the bug report before replying.

Your reply doesn't address the issue AT ALL. It addresses an entirely
different matter.

Martin-Éric