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
signature.asc
Description: Digital signature
