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? Thanks, Qu > > Thanks, > Qu >
