Re: [PATCH 1/2] btrfs: fix space cache corruption and potential double allocations

[Omar Sandoval <osandov@osandov.com>]

On Thu, Aug 18, 2022 at 02:22:00AM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2022-08-17 at 16:59 -0700, Omar Sandoval wrote:
> > I'm working on a tool that can be run on a mounted filesystem to
> > detect
> > most of the corruptions that could result from this bug. I'll share
> > that
> > in the next couple of days.
> 
> That sounds quite good.
> 
> Maybe such thing should find it's way into btrfs-progs.
> 
> I remember back then whether there were some corruption issues that
> occurred with holes in compressed files, there were also some ways to
> search for files which may have been affected.
> 
> So I mean such things wouldn't be the day2day tools of btrfs-progs, but
> could be helpful to those who'd like to investigate more... and having
> it as part of btrfs-progrs would make them much more accessible to end-
> users (no need to search for it, no need to compile it, no need to
> trust their author (well at least not more than they anyway need to
> trust btrfs-progs)).
> 
> 
> > 
> > From what I've found, it's much more likely to happen if you delete a
> > lot of data soon after boot with space_cache=v2/nospace_cache and
> > discard/discard=sync. I can't say that it'd never happen outside of
> > those conditions, but I suspect that it's much harder to hit
> > otherwise.
> 
> Okay, but deletion *is* necessary, right?

Yes, but metadata deletions also count, so basically any modification
results in a deletion. We haven't seen this in practice, but I couldn't
find anything that would make it impossible.

In place modifications of files also result in COW and deletion of the
old data, so that also technically counts.