Re: [PATCH v4 3/9] btrfs: add support for inserting raid stripe extents

[Johannes Thumshirn <Johannes.Thumshirn@wdc.com>]

On 13.12.22 09:54, hch@infradead.org wrote:
> On Tue, Dec 13, 2022 at 08:47:48AM +0000, Johannes Thumshirn wrote:
>> The reasoning behind this is possibly lower write amplification, as
>> we can exploit the merging of delayed_refs. See this hunk for example:
> 
> I'm curious how much of that merging happens, and how much would also
> be handled by not splitting the ordered_extent to start with as

What I've discovered is, for a 2 minute fio randrw run, it's in the upper
2 digit to 3 digit class (obviously depends on the pattern fio spits out).

I've discovered that the hard way when I've added the leak check on unmount out
of curiosity.

> suggested in my previous mail.  I'll have do defer to the people
> more familiar with btrfs again, but if you need to delay the tree
> update to reduce the write amp, shouldn't it use it's own set of
> delayed refs instead of piggy backing on the rather unrelated file
> to logical mapping ones?
> 

Let me think about that. I need to contemplate on the pros and cons
of this myself first. I agree it's abusing the data refs but I haven't
had a better solution.