Re: [PATCH URGENT v1.1 0/2] btrfs-progs: Fix the nobarrier behavior of write

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]

On Wed, Mar 27, 2019 at 03:07:48PM +0100, Adam Borowski wrote:
> On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
> > This urgent patchset can be fetched from github:
> > https://github.com/adam900710/btrfs-progs/tree/flush_super
> > Which is based on v4.20.2.
> > 
> > Before this patch, btrfs-progs writes to the fs has no barrier at all.
> > All metadata and superblock are just buffered write, no barrier between
> > super blocks and metadata writes at all.
> > 
> > No wonder why even clear space cache can cause serious transid
> > corruption to the originally good fs.
> > 
> > Please merge this fix as soon as possible as I really don't want to see
> > btrfs-progs corrupting any fs any more.
> 
> How often does this happen in practice?  I'm slightly incredulous about
> btrfs-progs crashing often.   Especially that pwrite() is buffered on the
> kernel side, so we'd need a _kernel_ crash (usually a power loss) to break
> consistency.  Obviously, a potential data loss bug is always something that
> needs fixing, I'm just wondering about severity.

   It's a pretty regular event -- there's often a segfault or other
uncontrolled exit when running btrfs check on a broken filesystem.
It's usually hard to say whether that kind of thing (in --repair mode)
is causing additional corruption, or whether it's not fixing anything,
or whether it's fixing something and exposing the next error down.

> Or do I understand this wrong?
> 
> Asking because Dimitri John Ledkov stepped down as Debian's maintainer of
> this package, and I'm taking up the mantle (with Nicholas D Steeves being
> around) -- modulo any updates other than important bug fixes being on hold
> because of Debian's freeze.  Thus, I wonder if this is important enough to
> ask for a freeze exception.

   My ha'penn'orth: it's probably not worth asking for a freeze
exception -- I don't think it makes normal operation of the btrfs
progs actively dangerous, but it's increasing risk somewhat on what
are generally pretty rare operations in the lifetime of a filesystem.
It's only the offline tools that are going to be affected here anyway
-- most of the use-cases for btrfs-progs are in telling the kernel
what to do, rather than modifying the FS directly.

   I'd say it's definitely worth fixing the issue upstream (which Qu
is doing), and then (if possible) backporting it to your maintained
packages after the Debian release.

[Other opinions are also available from alternative vendors].

   Hugo.

-- 
Hugo Mills             | Well, sir, the floor is yours. But remember, the
hugo@... carfax.org.uk | roof is ours!
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                                             The Goons

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]