Re: 'btrfs filesystem defragment' makes files explode in size, especially fallocated ones

[Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>]

On 8/6/24 11:23, Qu Wenruo wrote:

> When defrag happens, it triggers data COW, and screw up everything.

Yeah, making test files in NOCOW mode seems to prevent the issue.

> I'm not sure how high the value you set, but at least please do
> everything with default kernel config, not just crank the settings up.

Up to 50% of 32G RAM machine. More than enough for a 224M file.

Kernel defaults are meaningless anyway, as they are relative to RAM size. Even Linus admitted that: https://lwn.net/Articles/572921/

> And have you tried sync before compsize/fiemap?

Of course. I do sync on every step.

> If we try to lock the defrag range, to ensure them to land in a larger
> extent, I'm 100% sure MM guys won't be happy, it's blocking the most
> common way to reclaim memory.

Hmm, but couldn't Btrfs simply preallocate that space? I copied files much larger in size than the page cache and even entire RAM, they are totally fine as you could guess.
Is moving extents under the hood that different from copying files around?

> IIRC it's already in the document, although not that clear:
> 
>    The value is only advisory and the final size of the extents may
>    differ, depending on the state of the free space and fragmentation or
>    other internal logic.
> 
> To be honest, defrag is not recommended for modern extent based file
> systems already, thus there is no longer a common and good example to
> follow.
> 
> And for COW file systems, along with btrfs' specific bookend behavior,
> it brings a new level of complexity.
> 
> So overall, if you're not sure what the defrag internal logic is, nor
> have a clear problem you want to solve, do not defrag.

Well, I went into this hole for a reason.
I worked with some software piece which writes files sequentally, but in a very primitive POSIX-compliant way. For reference, ~17G file it produced was split into more than 1 million(!) extents. Basically shredding entire file into 16K pieces. Producing a no-joke access performance penalty even on SSD. In fact I only noticed the problem because of horrible disk performance with the file.

And I even tried to write it in NOCOW mode, but it didn't help, fragmentation level was the same. So it has nothing to do with CoW, it's Btrfs itself not really getting intentions of the software.
I'm not sure how it would behave with other filesystems, but for me it doesn't really look as a FS fault anyway.

So I ended up falling back to the old good defragmentation. Discovering the reported issue along the way, becaming a double-trouble for me.