Re: [PATCH v3 1/9] btrfs: delayed-ref: Introduce better documented delayed ref structures

[Qu Wenruo <wqu@suse.de>]

[snip]
>>> Looking at the dev
>>> docs and the description for 'offset' field in btrfs_file_extent_item I
>>> can sort of deduce that this field will only be different than null if
>>> this reference is for an extent which is shared between 2 snapshots.
>>
>> Don't forget reflink and data CoW.
>>
>> Like this:
>>
>> 	item 6 key (257 EXTENT_DATA 0) itemoff 15813 itemsize 53
>> 		generation 6 type 1 (regular)
>> 		extent data disk byte 13631488 nr 1048576
>> 		extent data offset 0 nr 4096 ram 1048576
>> 	item 7 key (257 EXTENT_DATA 4096) itemoff 15760 itemsize 53
>> 		generation 7 type 1 (regular)
>> 		extent data disk byte 14680064 nr 4096
>> 		extent data offset 0 nr 4096 ram 4096
>> 	item 8 key (257 EXTENT_DATA 8192) itemoff 15707 itemsize 53
>> 		generation 6 type 1 (regular)
>> 		extent data disk byte 13631488 nr 1048576
>> 		extent data offset 8192 nr 1040384 ram 1048576
>>
>> EXTENT_DATA items at 0 and 8K offset are original from one larger
>> extent, EXTENT_DATA item at 4K offset is newly written one.
> 
> Okay this makes sense, however if we take item 8 being inserted then
> according to the comments, the 'offset' member for this data ref will be
> 0 since 8k (from key.offset) - 8k (from btrfs_file_extent_offset)?  WHy
> is that, shouldn't the offset here be 8k rather than 0?

To avoid creating a new data backref item.

I don't like this idea too, it makes btrfs check, especially lowmem
mode, pretty slow.

If I'm going to re-design the on-disk format, this is definitely going
to disappear.
But the design is already here for a long long time, even it caused
problems before, we still need to follow the behavior.

Thanks,
Qu