[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
