On Tue, Nov 15, 2016 at 02:33:31PM +0800, Qu Wenruo wrote: > Hi, xfs guys and btrfs guys. > > Although the test case generic/372 exists for some time, I noticed that > btrfs always fails the test case, due to the difference in how btrfs > and xfs handle shared extents. > > The difference is, btrfs can handle shared extents which points to a subset > of a larger extent, so it doesn't need to split reflink source. > > In case of the test case. > > On Disk Extent A: > Bytenr X > |<-----------Data=0x61, Length=320K---------------------------| > > > File1: File Extent 0 -> Extent A, offset=0, referred len=320K > > File2: File Extent 0 -> Hole > File Extent 64K -> Extent A, offset=192k, refferred len=64k > File Extent 128K -> Hole > File Extent 192K -> Extent A, offset=64k, refferred len=64k > > Unlike Xfs, Btrfs don't split the source extent, as its file extent has more > fields which can handle offset/length inside the large extent.
XFS doesn't split the extent either, internally. The FIEMAP implementation cross-references extent data with the refcount records, using extra struct fiemap_extent to report precisely which blocks are shared and which aren't. ocfs2 exhibits the same behavior. It's only btrfs that reports file1 as having one big shared extent when only parts of that extent are actually shared. I'd rather btrfs only report blocks that are actually shared as shared, but since fiemap results can be obsolete as soon as the ioctl returns I don't consider it a huge priority. > The btrfs way to handle shared extent has its pros and cons. > For example, it's very flex, but it wastes more space for COW since the > whole extent can only be freed after all referencer is freed. Wait, what? So if I reflinked a single block of file1 into file3 and then deleted file1 and file2, btrfs would hold on to all 320K? > But since the test case is generic test case, I think it doesn't take such > btrfs behavior into consideration. > So it always fails on btrfs. > > How about moving it to xfs specific tests? I'd prefer the testcase be left in generic/ and _notrun'd on btrfs since two of the three reflink fses have this behavior. (Assuming the btrfs behavior doesn't get changed.) --D > > Thanks, > Qu > > -- 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
