diff mbox

[3/4] xfstests: Add support for btrfs in 015

Message ID bebfc5c98e0fb878f55c1312d8750ce7b7f82e07.1311776403.git.sbehrens@giantdisaster.de (mailing list archive)
State Not Applicable
Headers show

Commit Message

Stefan Behrens July 28, 2011, 8:28 a.m. UTC
Added btrfs to the list of supported filesystems for test 015, and
increased free space reporting tolerance to 10% for btrfs.
Replaced the call to _scratch_mkfs_xfs with the XFS specific size
parameter by the generic one for sized filesystem creation which is
_scratch_mkfs_sized.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
---
 015 |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

Comments

Christoph Hellwig July 28, 2011, 8:47 a.m. UTC | #1
On Thu, Jul 28, 2011 at 10:28:00AM +0200, Stefan Behrens wrote:
> Added btrfs to the list of supported filesystems for test 015, and
> increased free space reporting tolerance to 10% for btrfs.
> Replaced the call to _scratch_mkfs_xfs with the XFS specific size
> parameter by the generic one for sized filesystem creation which is
> _scratch_mkfs_sized.

ACK for the _scratch_mkfs_sized changed, but I'm really curious why
we would allow so much more tolerance for btrfs.

And again, why can't these be marked generic?

--
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
Stefan Behrens July 28, 2011, 5:54 p.m. UTC | #2
On 7/28/2011 10:47 AM, Christoph Hellwig wrote:
> On Thu, Jul 28, 2011 at 10:28:00AM +0200, Stefan Behrens wrote:
>> Added btrfs to the list of supported filesystems for test 015, and
>> increased free space reporting tolerance to 10% for btrfs.
>> Replaced the call to _scratch_mkfs_xfs with the XFS specific size
>> parameter by the generic one for sized filesystem creation which is
>> _scratch_mkfs_sized.
> 
> ACK for the _scratch_mkfs_sized changed, but I'm really curious why
> we would allow so much more tolerance for btrfs.
> 
> And again, why can't these be marked generic?

To add a 10% tolerance for btrfs was a bad idea.
Since the output of df(1) is not yet reliable on btrfs volumes while
data is not flushed to disk, the better implementation would be to
either let this test fail, or to force a flush to disk before taking
the output of df(1).
The latter is what I have implemented now.

This is a demo of what currently happens:
# mkfs.btrfs -b 2048M --mixed $SCRATCH_DEV
WARNING! - Btrfs v0.19-104-gd0fa1a8-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

Created a data/metadata chunk of size 8388608
fs created label (null) on /dev/sdu1
        nodesize 4096 leafsize 4096 sectorsize 4096 size 2.00GB
Btrfs v0.19-104-gd0fa1a8-dirty
# mount $SCRATCH_DEV $SCRATCH_MNT
# df -k $SCRATCH_MNT
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdu1              2097152        28   2093040   1% /mnt3
# dd if=/dev/zero of=$SCRATCH_MNT/foo bs=1M
dd: writing `/mnt3/foo': No space left on device
1881+0 records in
1880+0 records out
1971322880 bytes (2.0 GB) copied, 7.61947 s, 259 MB/s
# df -k $SCRATCH_MNT
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdu1              2097152       756   2092304   1% /mnt3
# sync
# df -k $SCRATCH_MNT
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdu1              2097152   1928420    164640  93% /mnt3
# rm -f $SCRATCH_MNT/foo
# df -k $SCRATCH_MNT
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdu1              2097152   1928420    164640  93% /mnt3
# sync
# df -k $SCRATCH_MNT
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdu1              2097152       676   2092384   1% /mnt3
--
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
Christoph Hellwig July 28, 2011, 8:05 p.m. UTC | #3
On Thu, Jul 28, 2011 at 07:54:45PM +0200, Stefan Behrens wrote:
> To add a 10% tolerance for btrfs was a bad idea.
> Since the output of df(1) is not yet reliable on btrfs volumes while
> data is not flushed to disk, the better implementation would be to
> either let this test fail, or to force a flush to disk before taking
> the output of df(1).
> The latter is what I have implemented now.

I don't think it's correct either.  dellalloc blocks should be included
in the statfs output, else it it is pretty pointless.  Can you send the
patch to make it generic without that adjustment for now.

--
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 mbox

Patch

diff --git a/015 b/015
index 8f2be7c..7020e67 100755
--- a/015
+++ b/015
@@ -48,13 +48,13 @@  _free()
 }
 
 # real QA test starts here
-_supported_fs xfs
+_supported_fs xfs btrfs
 _supported_os IRIX Linux
 
 _require_scratch
 _require_nobigloopfs
 
-_scratch_mkfs_xfs -d size=50m >/dev/null || _fail "mkfs failed"
+_scratch_mkfs_sized `expr 50 \* 1024 \* 1024` >/dev/null || _fail "mkfs failed"
 _scratch_mount || _fail "mount failed"
 out=$SCRATCH_MNT/fillup.$$
 rm -f $seq.full
@@ -120,7 +120,12 @@  fi
 echo "free space after delete $free2" >> $seq.full
 
 echo -n "   !!! "
-_within_tolerance "free space" $free2 $free0 1% -v
+if [ $FSTYP = btrfs ]
+then
+	_within_tolerance "free space" $free2 $free0 10% -v
+else
+	_within_tolerance "free space" $free2 $free0 1% -v
+fi
 
 status=0
 exit