Re: [RFC] Btrfs design defect in extent backref ?

[Li Zefan <lizf@cn.fujitsu.com>]

Yan, Zheng wrote:
> On Fri, Aug 26, 2011 at 10:00 AM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> Yan, Zheng wrote:
>>> On Thu, Aug 25, 2011 at 3:56 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>>>> We have an offset in file extent to indicate its position in the
>>>> corresponding extent item in extent tree. We also have an offset in
>>>> extent item to indicate the start position of the file extent that
>>>> uses this item.
>>>>
>>>> The math is:
>>>>
>>>>    extent_item.extent_data_ref.offset = file_pos - file_extent.extent_offset.
>>>>
>>>>                       e1
>>>> disk extents:    |--------------|
>>>>                 ^
>>>>                 |                  e2
>>>>                 |          |-----------------|
>>>>                 |          |   ^
>>>>                 |          |   |
>>>>                 v          v   |
>>>> file extents:    |----- f1 -----|----- f2 -----|
>>>>
>>>> So it looks like e2.offset points to f1 not f2. Therefore given an extent item,
>>>> we'll have to search through all the file extents in an inode to find the
>>>> relative file extent in the worst case, which makes this field somewhat useless.
>>>>
>>>
>>> The reason for this is reducing number of file extent backref itmes.
>>
>> It seems to me a rare case, which isn't worth the complexity and inconvenience
>> it brings, and it requires an extra field (.count).
>>
> Random write workload isn't a rare case.
> 

Ah, I was thinking about the clone ioctl, and ignoring other situations.

Thanks for your clarification.