Yan, Zheng wrote: > On Fri, Aug 26, 2011 at 10:00 AM, Li Zefan <l...@cn.fujitsu.com> wrote: >> Yan, Zheng wrote: >>> On Thu, Aug 25, 2011 at 3:56 PM, Li Zefan <l...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
