On 2/18/19 1:00 PM, Qu Wenruo wrote:
On 2019/2/11 下午10:23, Qu Wenruo wrote:
[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.
Is there any extra suggestion on the wording about the anti-initiative
offset used in data backref?
My personal suggestion is doing simplification first like your patches,
then to discuss "design" in detail.
Thanks,
Qu
Thanks,
Qu
