Re: btrfs metadata reclaim behavior/performance characteristics

[Nikolay Borisov <nborisov@suse.com>]

On 18.05.2017 17:45, Liu Bo wrote:
> On Thu, May 18, 2017 at 11:40:05AM +0300, Nikolay Borisov wrote:

<ommitted for brevity>

> 
> Just some random thoughts here.
> 
> Hmm, not sure if this matters, but fstests now doesn't set --mixed even if the
> disk size is as small as 256mb.  So are you testing a mixed btrfs or not?

You are right that fstest only sets mixed mode in case the filesystem is
less than or equal to 100mb. IN this case the fs is 256mb which means
mixed mode _is not_ set.

> 
> So now we've observed there're too many 'commit transaction' happening, I think it's because via commiting transaction it doesn't reclaim enough metadata space, esp. looks like space->bytes_may_use is not reduced somehow.

You've given me the idea to basically compare the state of the various
space_info counters after each transaction commit. Before and after the
ticketed work. Also what makes you believe it's the commit transaction
itself not freeing enough memory and not some of the other, "cheaper"
flush states?

> 
> The metadata space_info->bytes_may_use may come from:
> 1) 1K file with buffered IO ends up living in btree leaf, so it will contribute to the number,
> 2) if it's mixed btrfs, then 1k file with direct IO ends up with creating a 4k extent in mixed block group.
> 3) while writing 1k files, metadata is reserved to make it run, and when to release depends on writeback (in the buffered IO case) or endio (in the direct IO case)
> 
> When running several commit transaction concurrently, if one has entered TRANS_STATE_COMMIT_START state, others just wait there, have you observed that if each commit transaction actually writes superblock in the end?

Haven't gone that far, will have to instrument the code to confirm this.
What exactly should writing the superblock reveal?

> 
> Thanks,
> 
> -liubo
> 
>>

<omitted for brevity>