Re: Confused by btrfs quota group accounting

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

[-- Attachment #1.1: Type: text/plain, Size: 2094 bytes --]



On 2019/6/23 下午9:42, Andrei Borzenkov wrote:
> 23.06.2019 14:29, Qu Wenruo пишет:
>>
>>
>> BTW, so many fragmented extents, this normally means your system has
>> very high memory pressure or lack of memory, or lack of on-disk space.
> 
> It is 1GiB QEMU VM with vanilla Tumbleweed with GNOME desktop; nothing
> runs except user GNOME session. Does it fit "high memory pressure"
> definition?

1GiB Vram? That's very easy to trigger memory pressure.
I'm not 100% sure about the percentage page cache can use, but 1/8 would
be a safe guess.
Which means, you can only write at most 128M before triggering writeback.
Considering other program uses some page cache, you have less available
page caches for filesystem.

> 
>> Above 100MiB should be in one large extent, not split into so many small
>> ones.
>>
> 
> OK, so this is where I was confused. I was sure that filefrag returns
> true "physical" extent layout. It seems that in filefrag output
> consecutive extents are merged giving false picture of large extent
> instead of many small ones. Filefrag shows 5 ~200MiB extents, not over
> 30 smaller ones.

Btrfs does file extent mapping merge at fiemap reporting time.
Personally speaking, I don't know why user would expect real extent mapping.
As long as the all these extents have the same flags, continuous
address, then merging them shouldn't be a problem.

In fact, after viewing the real on-disk extent mapping, it's possible to
explain just by the fiemap result, but using fiemap result alone is
indeed much harder to expose such case.

For your use case, it's already deep into the implementation, thus I
recommend low level tools like "btrfs ins dump-tree" to discover the
underlying extent mapping.

> 
> Is it how generic IOCTL is designed to work or is it something that
> btrfs does internally? This *is* confusing.
> 
> In any case, thank you for clarification, this makes sense now.

AFAIK, we should put this into the btrfs(5) man page as an special use
case. Along with btrfs extent booking.

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]