At 11/15/2016 04:57 PM, Christoph Hellwig wrote:
On Tue, Nov 15, 2016 at 04:14:10PM +0800, Qu Wenruo wrote:
Since btrfs always return the whole extent even part of it is shared
with other files, so the hole/extent counts differs for "file1" in this
test case.
This would need an extremly detailed comment in the test case on why
btrfs is skipped IFF we decide to apply it. That being siad I think
reporing shared extents incorrectly is a bug independent of how they
are implemented internally.
I don't think it's a bug.
It's just the different granularity on SHARED flag.
SHARED flag returned by btrfs has its meaning, since it is shared by
other files/subvolumes.
And further more, due to the extent booking mechanism in btrfs, one
extent won't be modified/removed until all its referencer got removed.
This quite lazy behavior co-operates with the lazy SHARED flag well.
So IMHO it's just granularity difference not a bug.
Not to mention that, fiemap bytenr returned from btrfs doesn't makes
sense at all, unless you know how to map it into device.
From this aspect, btrfs fiemap is already a so-called "bug" compared to
xfs/ext*.
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
