| Message ID | 20161115081410.6779-1-quwenruo@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/common/rc b/common/rc index e3b54ec..6c3de22 100644 --- a/common/rc +++ b/common/rc @@ -3230,6 +3230,16 @@ _normalize_mount_options() echo $MOUNT_OPTIONS | sed -n 's/-o\s*\(\S*\)/\1/gp'| sed 's/,/ /g' } +# skip test if FSTYP is in the black list +_exclude_fs_type() +{ + while [ $# -gt 0 ]; do + if [ $FSTYP == $1 ]; then + _notrun "fs type \"$1\" is not allowed in this test" + fi + done +} + # skip test if MOUNT_OPTIONS contains the given strings _exclude_scratch_mount_option() { diff --git a/tests/generic/372 b/tests/generic/372 index 31dff20..5e4cfff 100755 --- a/tests/generic/372 +++ b/tests/generic/372 @@ -45,6 +45,7 @@ _cleanup() # real QA test starts here _supported_os Linux _supported_fs generic +_exclude_fs_type btrfs _require_scratch_reflink _require_fiemap
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. For example: /------ File 1 Extent 0-------------\ / \ |<----------Extent A------------------>| \ / \ / \ File 2/ \ File 2/ Ext 0~4K Ext 64k~68K In that case, fiemap on File 1 will only return 1 large extent A with SHARED flag. While XFS will split it into 3 extents, first and last 4K with SHARED flag while the rest without SHARED flag. This makes the test case meaningless as btrfs doesn't follow such assumption. So black list btrfs for this test case to avoid false alert. Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> --- common/rc | 10 ++++++++++ tests/generic/372 | 1 + 2 files changed, 11 insertions(+)