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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2024/8/7 08:12, Hanabishi 写道:
> On 8/6/24 22:10, Qu Wenruo wrote:
>
>> But you're using btrfs for its super fast snapshot, and that will force
>> data COW, causing all the complexity.
>
> For me the data checksumming is more of a selling point. I.e. yes, using
> Btrfs in a NOCOW mode kinda defies the point.

In that data csum (and COW) case, then I guess one has to choose if
preallocation is really wanted very carefully.

Or it's super easy to cause unexpected on-disk space waste.
(COW is already going to cause space waste, but preallocation amplifies
that much faster)

>
>> It means, even you have written 10GiB new data, as long as our
>> transaction is not committed, you will only get all the old data after a
>> power loss (unless it's explicitly fsynced).
>> That's another point very different from old non-COW filesystems.
>>
>> Instead "commit=" with a lower value is more helpful for btrfs, but that
>> would cause more metadata writes though.
>
> What about "flushoncommit" mount option? Does it make data view more
> resilient?
>

If combined with lower commit= value, yes, it will be data view more
consistent with transactions.

But as usual, it amplifies the metadata writes, which is already pretty
bad for btrfs.

And may worse the extra space usage problem too, if using data COW (as
it forces dirty pages writeback at every transaction commit, causing
smaller writes)

(I guess a UPS would be better for everyone except the budget?)

Thanks,
Qu