[PATCH] btrfs: check truncate can update file size correctly when truncate fails

[PATCH] btrfs: check truncate can update file size correctly when truncate fails

[Wang Xiaoguang]

In btrfs, when truncate operation fails for enospc reason, file may still
have some disk blocks, but it will fail to update filesize accordingly.

Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
---
 tests/btrfs/124     | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/124.out |  2 ++
 tests/btrfs/group   |  1 +
 3 files changed, 89 insertions(+)
 create mode 100755 tests/btrfs/124
 create mode 100644 tests/btrfs/124.out

diff --git a/tests/btrfs/124 b/tests/btrfs/124
new file mode 100755
index 0000000..1a13ddf
--- /dev/null
+++ b/tests/btrfs/124
@@ -0,0 +1,86 @@
+#! /bin/bash
+# FS QA Test 124
+#
+# Test whether truncate can update file size correctly when truncate fails
+#
+# When truncate operation fails for enospc reason, file will still
+# have some disk blocks, but it will fail to update filesize accordingly.
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2016 Fujitsu.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1	# failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+	cd /
+	rm -f $tmp.*
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+. ./common/reflink
+
+# remove previous $seqres.full before test
+rm -f $seqres.full
+
+# Modify as appropriate.
+_supported_fs generic
+_supported_os Linux
+_supported_fs btrfs
+_require_scratch_reflink
+
+MKFS_OPTIONS="-O ^mixed-bg"
+_scratch_mkfs_sized $((101 * 1024 * 1024)) >> $seqres.full 2>&1
+_scratch_mount
+
+blocksize=$((128 * 1024))
+file="$SCRATCH_MNT/testfile"
+filesize=$((12 * 1024 * 1024 * 1024))
+nr=$((filesize / blocksize))
+
+# write the initial block for later reflink
+_pwrite_byte 0xcdcdcdcd 0 $blocksize $file > /dev/null
+
+# use reflink to create the rest of the file, whose all extents are all
+# pointing to the first extent
+for ((i = 1; i < $nr; i++)); do
+	_reflink_range $file 0 $file $(($i * $blocksize)) $blocksize > /dev/null
+done
+
+$XFS_IO_PROG -f -c "truncate 0" $file > /dev/null 2>&1
+disk_usage=`du $file | $AWK_PROG '{print $1}'`
+new_filesize=`ls -l $file | $AWK_PROG '{print $5}'`
+if [ $disk_usage -gt 0 ] && [ $new_filesize -eq 0 ]; then
+	echo "after truncate, file size is 0, but file still owns disk blocks"
+	status=1
+	exit
+fi
+
+echo "Silence is golden"
+# success, all done
+status=0
+exit
diff --git a/tests/btrfs/124.out b/tests/btrfs/124.out
new file mode 100644
index 0000000..d7339e6
--- /dev/null
+++ b/tests/btrfs/124.out
@@ -0,0 +1,2 @@
+QA output created by 124
+Silence is golden
diff --git a/tests/btrfs/group b/tests/btrfs/group
index 5a26ed7..8b5050e 100644
--- a/tests/btrfs/group
+++ b/tests/btrfs/group
@@ -126,3 +126,4 @@
 121 auto quick snapshot qgroup
 122 auto quick snapshot qgroup
 123 auto quick qgroup
+124 auto quick metadata
-- 
1.8.3.1

Re: [PATCH] btrfs: check truncate can update file size correctly when truncate fails

[Eryu Guan]

On Thu, Jun 23, 2016 at 03:36:40PM +0800, Wang Xiaoguang wrote:
> In btrfs, when truncate operation fails for enospc reason, file may still
> have some disk blocks, but it will fail to update filesize accordingly.
> 
> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
> ---
>  tests/btrfs/124     | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  tests/btrfs/124.out |  2 ++
>  tests/btrfs/group   |  1 +
>  3 files changed, 89 insertions(+)
>  create mode 100755 tests/btrfs/124
>  create mode 100644 tests/btrfs/124.out
> 
> diff --git a/tests/btrfs/124 b/tests/btrfs/124
> new file mode 100755
> index 0000000..1a13ddf
> --- /dev/null
> +++ b/tests/btrfs/124
> @@ -0,0 +1,86 @@
> +#! /bin/bash
> +# FS QA Test 124
> +#
> +# Test whether truncate can update file size correctly when truncate fails
> +#
> +# When truncate operation fails for enospc reason, file will still
> +# have some disk blocks, but it will fail to update filesize accordingly.
> +#
> +#-----------------------------------------------------------------------
> +# Copyright (c) 2016 Fujitsu.  All Rights Reserved.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it would be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write the Free Software Foundation,
> +# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> +#-----------------------------------------------------------------------
> +#
> +
> +seq=`basename $0`
> +seqres=$RESULT_DIR/$seq
> +echo "QA output created by $seq"
> +
> +here=`pwd`
> +tmp=/tmp/$$
> +status=1	# failure is the default!
> +trap "_cleanup; exit \$status" 0 1 2 3 15
> +
> +_cleanup()
> +{
> +	cd /
> +	rm -f $tmp.*
> +}
> +
> +# get standard environment, filters and checks
> +. ./common/rc
> +. ./common/filter
> +. ./common/reflink
> +
> +# remove previous $seqres.full before test
> +rm -f $seqres.full
> +
> +# Modify as appropriate.
> +_supported_fs generic
> +_supported_os Linux
> +_supported_fs btrfs

Two "_supported_fs" here.

And I don't see any other btrfs-specific configs except MKFS_OPTIONS, is
it possible to make it a generic test?

> +_require_scratch_reflink
> +
> +MKFS_OPTIONS="-O ^mixed-bg"

Need comments on why testing with this MKFS_OPTIONS.

> +_scratch_mkfs_sized $((101 * 1024 * 1024)) >> $seqres.full 2>&1

101M is too small to make btrfs on ppc64 host for me.

> +_scratch_mount
> +
> +blocksize=$((128 * 1024))
> +file="$SCRATCH_MNT/testfile"
> +filesize=$((12 * 1024 * 1024 * 1024))

Comments on these numbers picked would be good, i.e. why 128k blocksize,
why 12M filesize. Any special reason or just good enough for the test?

> +nr=$((filesize / blocksize))
> +
> +# write the initial block for later reflink
> +_pwrite_byte 0xcdcdcdcd 0 $blocksize $file > /dev/null
> +
> +# use reflink to create the rest of the file, whose all extents are all
> +# pointing to the first extent
> +for ((i = 1; i < $nr; i++)); do
> +	_reflink_range $file 0 $file $(($i * $blocksize)) $blocksize > /dev/null
> +done

It's not clear to me in test description that why reflink is needed in
this test. Perhaps test description and comments above can be updated to
reflect the purpose of reflink?

> +
> +$XFS_IO_PROG -f -c "truncate 0" $file > /dev/null 2>&1
> +disk_usage=`du $file | $AWK_PROG '{print $1}'`
> +new_filesize=`ls -l $file | $AWK_PROG '{print $5}'`

I think "stat -c %s $file" is much easier :)

> +if [ $disk_usage -gt 0 ] && [ $new_filesize -eq 0 ]; then
> +	echo "after truncate, file size is 0, but file still owns disk blocks"
> +	status=1
> +	exit
> +fi
> +
> +echo "Silence is golden"
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/btrfs/124.out b/tests/btrfs/124.out
> new file mode 100644
> index 0000000..d7339e6
> --- /dev/null
> +++ b/tests/btrfs/124.out
> @@ -0,0 +1,2 @@
> +QA output created by 124
> +Silence is golden
> diff --git a/tests/btrfs/group b/tests/btrfs/group
> index 5a26ed7..8b5050e 100644
> --- a/tests/btrfs/group
> +++ b/tests/btrfs/group
> @@ -126,3 +126,4 @@
>  121 auto quick snapshot qgroup
>  122 auto quick snapshot qgroup
>  123 auto quick qgroup
> +124 auto quick metadata

Add it to 'clone' group as well?

Thanks,
Eryu

Re: [PATCH] btrfs: check truncate can update file size correctly when truncate fails

[Christoph Hellwig]

On Thu, Jun 23, 2016 at 03:36:40PM +0800, Wang Xiaoguang wrote:
> In btrfs, when truncate operation fails for enospc reason, file may still
> have some disk blocks, but it will fail to update filesize accordingly.

Any reason this isn't a generic test?  Seems nothing in the test case
really is btrfs specific.

Re: [PATCH] btrfs: check truncate can update file size correctly when truncate fails

[Wang Xiaoguang]

hello,

Thanks for your comments.
I will update the patch according to your comments and make it to 
generic tests.

Regards,
Xiaoguang Wang

On 06/23/2016 04:27 PM, Eryu Guan wrote:
> On Thu, Jun 23, 2016 at 03:36:40PM +0800, Wang Xiaoguang wrote:
>> In btrfs, when truncate operation fails for enospc reason, file may still
>> have some disk blocks, but it will fail to update filesize accordingly.
>>
>> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
>> ---
>>   tests/btrfs/124     | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   tests/btrfs/124.out |  2 ++
>>   tests/btrfs/group   |  1 +
>>   3 files changed, 89 insertions(+)
>>   create mode 100755 tests/btrfs/124
>>   create mode 100644 tests/btrfs/124.out
>>
>> diff --git a/tests/btrfs/124 b/tests/btrfs/124
>> new file mode 100755
>> index 0000000..1a13ddf
>> --- /dev/null
>> +++ b/tests/btrfs/124
>> @@ -0,0 +1,86 @@
>> +#! /bin/bash
>> +# FS QA Test 124
>> +#
>> +# Test whether truncate can update file size correctly when truncate fails
>> +#
>> +# When truncate operation fails for enospc reason, file will still
>> +# have some disk blocks, but it will fail to update filesize accordingly.
>> +#
>> +#-----------------------------------------------------------------------
>> +# Copyright (c) 2016 Fujitsu.  All Rights Reserved.
>> +#
>> +# This program is free software; you can redistribute it and/or
>> +# modify it under the terms of the GNU General Public License as
>> +# published by the Free Software Foundation.
>> +#
>> +# This program is distributed in the hope that it would be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program; if not, write the Free Software Foundation,
>> +# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
>> +#-----------------------------------------------------------------------
>> +#
>> +
>> +seq=`basename $0`
>> +seqres=$RESULT_DIR/$seq
>> +echo "QA output created by $seq"
>> +
>> +here=`pwd`
>> +tmp=/tmp/$$
>> +status=1	# failure is the default!
>> +trap "_cleanup; exit \$status" 0 1 2 3 15
>> +
>> +_cleanup()
>> +{
>> +	cd /
>> +	rm -f $tmp.*
>> +}
>> +
>> +# get standard environment, filters and checks
>> +. ./common/rc
>> +. ./common/filter
>> +. ./common/reflink
>> +
>> +# remove previous $seqres.full before test
>> +rm -f $seqres.full
>> +
>> +# Modify as appropriate.
>> +_supported_fs generic
>> +_supported_os Linux
>> +_supported_fs btrfs
> Two "_supported_fs" here.
>
> And I don't see any other btrfs-specific configs except MKFS_OPTIONS, is
> it possible to make it a generic test?
>
>> +_require_scratch_reflink
>> +
>> +MKFS_OPTIONS="-O ^mixed-bg"
> Need comments on why testing with this MKFS_OPTIONS.
>
>> +_scratch_mkfs_sized $((101 * 1024 * 1024)) >> $seqres.full 2>&1
> 101M is too small to make btrfs on ppc64 host for me.
>
>> +_scratch_mount
>> +
>> +blocksize=$((128 * 1024))
>> +file="$SCRATCH_MNT/testfile"
>> +filesize=$((12 * 1024 * 1024 * 1024))
> Comments on these numbers picked would be good, i.e. why 128k blocksize,
> why 12M filesize. Any special reason or just good enough for the test?
>
>> +nr=$((filesize / blocksize))
>> +
>> +# write the initial block for later reflink
>> +_pwrite_byte 0xcdcdcdcd 0 $blocksize $file > /dev/null
>> +
>> +# use reflink to create the rest of the file, whose all extents are all
>> +# pointing to the first extent
>> +for ((i = 1; i < $nr; i++)); do
>> +	_reflink_range $file 0 $file $(($i * $blocksize)) $blocksize > /dev/null
>> +done
> It's not clear to me in test description that why reflink is needed in
> this test. Perhaps test description and comments above can be updated to
> reflect the purpose of reflink?
>
>> +
>> +$XFS_IO_PROG -f -c "truncate 0" $file > /dev/null 2>&1
>> +disk_usage=`du $file | $AWK_PROG '{print $1}'`
>> +new_filesize=`ls -l $file | $AWK_PROG '{print $5}'`
> I think "stat -c %s $file" is much easier :)
>
>> +if [ $disk_usage -gt 0 ] && [ $new_filesize -eq 0 ]; then
>> +	echo "after truncate, file size is 0, but file still owns disk blocks"
>> +	status=1
>> +	exit
>> +fi
>> +
>> +echo "Silence is golden"
>> +# success, all done
>> +status=0
>> +exit
>> diff --git a/tests/btrfs/124.out b/tests/btrfs/124.out
>> new file mode 100644
>> index 0000000..d7339e6
>> --- /dev/null
>> +++ b/tests/btrfs/124.out
>> @@ -0,0 +1,2 @@
>> +QA output created by 124
>> +Silence is golden
>> diff --git a/tests/btrfs/group b/tests/btrfs/group
>> index 5a26ed7..8b5050e 100644
>> --- a/tests/btrfs/group
>> +++ b/tests/btrfs/group
>> @@ -126,3 +126,4 @@
>>   121 auto quick snapshot qgroup
>>   122 auto quick snapshot qgroup
>>   123 auto quick qgroup
>> +124 auto quick metadata
> Add it to 'clone' group as well?
>
> Thanks,
> Eryu
>
>

[PATCH v2] geceric/362: check truncate can update file size correctly when truncate fails

[Wang Xiaoguang]

In btrfs, when truncate operation fails for enospc reason, file may still
have some disk blocks, but it will fail to update filesize accordingly.

Kernel commit c0d2f61 has fixed this bug for btrfs:
    btrfs: fix disk_i_size update bug when ftruncate() fails

Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
---
v2: move this test to generic test and add comments why testcase
use reflink.
---
 tests/generic/362     | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/generic/362.out |   2 +
 tests/generic/group   |   1 +
 3 files changed, 104 insertions(+)
 create mode 100755 tests/generic/362
 create mode 100644 tests/generic/362.out

diff --git a/tests/generic/362 b/tests/generic/362
new file mode 100755
index 0000000..ba6024f
--- /dev/null
+++ b/tests/generic/362
@@ -0,0 +1,101 @@
+#! /bin/bash
+# FS QA Test 362
+#
+# Test whether truncate can update file size correctly when truncate fails
+#
+# When truncate operation fails for enospc reason, file will still
+# have some disk blocks, but sometimes it will fail to update filesize
+# accordingly.
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2016 Fujitsu.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1	# failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+	cd /
+	rm -f $tmp.*
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+. ./common/reflink
+
+# remove previous $seqres.full before test
+rm -f $seqres.full
+
+# Modify as appropriate.
+_supported_fs generic
+_supported_os Linux
+_require_scratch_reflink
+
+_scratch_mkfs_sized $((256 * 1024 * 1024)) >> $seqres.full 2>&1
+_scratch_mount
+
+testfile="$SCRATCH_MNT/testfile"
+
+# fill this fs with some space, which will reduce test time.
+$XFS_IO_PROG -f -c "pwrite 0 168M" $SCRATCH_MNT/file.temp > /dev/null
+
+# because btrfs separates data and metadata, and this test needs
+# truncate(2) fails for metadata ENOSPC reason to have test, so
+# here we choose to use reflink to consume much metadata. In btrfs,
+# truncate(2) will call internal start_transaction() to reserve
+# metadata to do truncate job, if it couldn't reserve more,
+# truncate(2) fails for ENOSPC reason.
+#
+# here this 12GB file size is choosed deliberately, which would
+# consume much metadata space by using reflink and make truncate
+# it will fail for ENOSPC reason.
+extentsize=$((128 * 1024))
+filesize=$((12 * 1024 * 1024 * 1024))
+nr=$((filesize / extentsize))
+
+# write the initial extent for later reflink
+_pwrite_byte 0xcdcdcdcd 0 $extentsize $testfile > /dev/null
+
+for ((i = 1; i < $nr; i++)); do
+	_reflink_range $testfile 0 $testfile $(($i * $extentsize))\
+		$extentsize > /dev/null
+	if [ $? -ne 0 ]; then
+		break;
+	fi
+done
+
+$XFS_IO_PROG -f -c "truncate 0" $testfile > /dev/null 2>&1
+disk_usage=`du $testfile | $AWK_PROG '{print $1}'`
+new_filesize=`stat -c %s $testfile`
+if [ $disk_usage -gt 0 ] && [ $new_filesize -eq 0 ]; then
+	echo "after truncate, file size is 0, but file still owns disk blocks"
+	status=1
+	exit
+fi
+
+echo "Silence is golden"
+# success, all done
+status=0
+exit
diff --git a/tests/generic/362.out b/tests/generic/362.out
new file mode 100644
index 0000000..0ff4090
--- /dev/null
+++ b/tests/generic/362.out
@@ -0,0 +1,2 @@
+QA output created by 362
+Silence is golden
diff --git a/tests/generic/group b/tests/generic/group
index 7491282..b208f99 100644
--- a/tests/generic/group
+++ b/tests/generic/group
@@ -364,3 +364,4 @@
 359 auto quick clone
 360 auto quick metadata
 361 auto quick
+362 auto metadata clone
-- 
2.9.0

Re: [PATCH v2] geceric/362: check truncate can update file size correctly when truncate fails

[Eryu Guan]

On Thu, Jun 30, 2016 at 04:25:49PM +0800, Wang Xiaoguang wrote:
> In btrfs, when truncate operation fails for enospc reason, file may still
> have some disk blocks, but it will fail to update filesize accordingly.
> 
> Kernel commit c0d2f61 has fixed this bug for btrfs:
>     btrfs: fix disk_i_size update bug when ftruncate() fails
> 
> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
> ---
> v2: move this test to generic test and add comments why testcase
> use reflink.

Thanks for the updated version. Did it fail for you when testing on
unpatched kernel? I ran the test more than 10 times on 4.6 kernel (which
doesn't have the fix) and all passed, as well as RHEL7 kernel.

Can you please confirm?

Thanks,
Eryu

Re: [PATCH v2] geceric/362: check truncate can update file size correctly when truncate fails

[Wang Xiaoguang]

hello,

On 06/30/2016 09:52 PM, Eryu Guan wrote:
> On Thu, Jun 30, 2016 at 04:25:49PM +0800, Wang Xiaoguang wrote:
>> In btrfs, when truncate operation fails for enospc reason, file may still
>> have some disk blocks, but it will fail to update filesize accordingly.
>>
>> Kernel commit c0d2f61 has fixed this bug for btrfs:
>>      btrfs: fix disk_i_size update bug when ftruncate() fails
>>
>> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
>> ---
>> v2: move this test to generic test and add comments why testcase
>> use reflink.
> Thanks for the updated version. Did it fail for you when testing on
> unpatched kernel? I ran the test more than 10 times on 4.6 kernel (which
> doesn't have the fix) and all passed, as well as RHEL7 kernel.
>
> Can you please confirm?
OK, please wait a while :)

Regards,
Xiaoguang Wang
>
> Thanks,
> Eryu
>
>

Re: [PATCH v2] geceric/362: check truncate can update file size correctly when truncate fails

[Wang Xiaoguang]

hello,

On 06/30/2016 09:52 PM, Eryu Guan wrote:
> On Thu, Jun 30, 2016 at 04:25:49PM +0800, Wang Xiaoguang wrote:
>> In btrfs, when truncate operation fails for enospc reason, file may still
>> have some disk blocks, but it will fail to update filesize accordingly.
>>
>> Kernel commit c0d2f61 has fixed this bug for btrfs:
>>      btrfs: fix disk_i_size update bug when ftruncate() fails
>>
>> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
>> ---
>> v2: move this test to generic test and add comments why testcase
>> use reflink.
> Thanks for the updated version. Did it fail for you when testing on
> unpatched kernel? I ran the test more than 10 times on 4.6 kernel (which
> doesn't have the fix) and all passed, as well as RHEL7 kernel.
>
> Can you please confirm?
I tested this case in v4.6-rc7-162-g415b35a and it failed as expected,
but I used the newest version btrfs-progs.
In RHEL7.2ga, its btrfs-progs version is btrfs-progs-3.19.1-1.el7.x86_64,
which is somewhat old. For small fs, it'll enable mixed mode for data and
metadata default, so the reflink operation in this test case does not 
consume
enough metadata, truncate operation can still succeed, then test will always
pass. I can create a big fs to have test, but then this fs will have more
metadata, which then need more reflink operations to consume metadata and
increase the test time greatly.

In mkfs.btrfs manpage, there is such description：
      versions up to 4.2.x forced the mixed mode for devices smaller
      than 1GiB. This has been removed in 4.3+ as it caused some
      usability issues.

Regards,
Xiaoguang Wang

>
> Thanks,
> Eryu
>
>

Re: [PATCH v2] geceric/362: check truncate can update file size correctly when truncate fails

[Eryu Guan]

On Fri, Jul 01, 2016 at 10:28:28AM +0800, Wang Xiaoguang wrote:
> hello,
> 
> On 06/30/2016 09:52 PM, Eryu Guan wrote:
> > On Thu, Jun 30, 2016 at 04:25:49PM +0800, Wang Xiaoguang wrote:
> > > In btrfs, when truncate operation fails for enospc reason, file may still
> > > have some disk blocks, but it will fail to update filesize accordingly.
> > > 
> > > Kernel commit c0d2f61 has fixed this bug for btrfs:
> > >      btrfs: fix disk_i_size update bug when ftruncate() fails
> > > 
> > > Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
> > > ---
> > > v2: move this test to generic test and add comments why testcase
> > > use reflink.
> > Thanks for the updated version. Did it fail for you when testing on
> > unpatched kernel? I ran the test more than 10 times on 4.6 kernel (which
> > doesn't have the fix) and all passed, as well as RHEL7 kernel.
> > 
> > Can you please confirm?
> I tested this case in v4.6-rc7-162-g415b35a and it failed as expected,
> but I used the newest version btrfs-progs.
> In RHEL7.2ga, its btrfs-progs version is btrfs-progs-3.19.1-1.el7.x86_64,
> which is somewhat old. For small fs, it'll enable mixed mode for data and
> metadata default, so the reflink operation in this test case does not
> consume
> enough metadata, truncate operation can still succeed, then test will always
> pass. I can create a big fs to have test, but then this fs will have more
> metadata, which then need more reflink operations to consume metadata and
> increase the test time greatly.
> 
> In mkfs.btrfs manpage, there is such description：
>      versions up to 4.2.x forced the mixed mode for devices smaller
>      than 1GiB. This has been removed in 4.3+ as it caused some
>      usability issues.

I also tested on 4.6 kernel with v4.6 btrfs-progs, it passed 10+ times
without a fail. I was testing on a 4vcpu kvm guest with 8G memory,
TEST_DEV and SCRATCH_DEV are all 15G in size, not sure if that matters.

Thanks,
Eryu

Re: [PATCH v2] geceric/362: check truncate can update file size correctly when truncate fails

[Wang Xiaoguang]

hello,

On 07/01/2016 10:55 AM, Eryu Guan wrote:
> On Fri, Jul 01, 2016 at 10:28:28AM +0800, Wang Xiaoguang wrote:
>> hello,
>>
>> On 06/30/2016 09:52 PM, Eryu Guan wrote:
>>> On Thu, Jun 30, 2016 at 04:25:49PM +0800, Wang Xiaoguang wrote:
>>>> In btrfs, when truncate operation fails for enospc reason, file may still
>>>> have some disk blocks, but it will fail to update filesize accordingly.
>>>>
>>>> Kernel commit c0d2f61 has fixed this bug for btrfs:
>>>>       btrfs: fix disk_i_size update bug when ftruncate() fails
>>>>
>>>> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
>>>> ---
>>>> v2: move this test to generic test and add comments why testcase
>>>> use reflink.
>>> Thanks for the updated version. Did it fail for you when testing on
>>> unpatched kernel? I ran the test more than 10 times on 4.6 kernel (which
>>> doesn't have the fix) and all passed, as well as RHEL7 kernel.
>>>
>>> Can you please confirm?
>> I tested this case in v4.6-rc7-162-g415b35a and it failed as expected,
>> but I used the newest version btrfs-progs.
>> In RHEL7.2ga, its btrfs-progs version is btrfs-progs-3.19.1-1.el7.x86_64,
>> which is somewhat old. For small fs, it'll enable mixed mode for data and
>> metadata default, so the reflink operation in this test case does not
>> consume
>> enough metadata, truncate operation can still succeed, then test will always
>> pass. I can create a big fs to have test, but then this fs will have more
>> metadata, which then need more reflink operations to consume metadata and
>> increase the test time greatly.
>>
>> In mkfs.btrfs manpage, there is such description：
>>       versions up to 4.2.x forced the mixed mode for devices smaller
>>       than 1GiB. This has been removed in 4.3+ as it caused some
>>       usability issues.
> I also tested on 4.6 kernel with v4.6 btrfs-progs, it passed 10+ times
> without a fail. I was testing on a 4vcpu kvm guest with 8G memory,
> TEST_DEV and SCRATCH_DEV are all 15G in size, not sure if that matters.
Sorry, I run this test case in v4.6, it still failed.
Would you please give me your kernel version and btrfs-progs version,
like this format: v4.6-rc7-162-g415b35a, which is generated by "describe",
then I can do some further investigation, thanks.

Regards,
Xiaoguang Wang
>
> Thanks,
> Eryu
>
>

Re: [PATCH v2] geceric/362: check truncate can update file size correctly when truncate fails

[Eryu Guan]

On Fri, Jul 01, 2016 at 03:05:41PM +0800, Wang Xiaoguang wrote:
> hello,
> 
> On 07/01/2016 10:55 AM, Eryu Guan wrote:
> > On Fri, Jul 01, 2016 at 10:28:28AM +0800, Wang Xiaoguang wrote:
> > > hello,
> > > 
> > > On 06/30/2016 09:52 PM, Eryu Guan wrote:
> > > > On Thu, Jun 30, 2016 at 04:25:49PM +0800, Wang Xiaoguang wrote:
> > > > > In btrfs, when truncate operation fails for enospc reason, file may still
> > > > > have some disk blocks, but it will fail to update filesize accordingly.
> > > > > 
> > > > > Kernel commit c0d2f61 has fixed this bug for btrfs:
> > > > >       btrfs: fix disk_i_size update bug when ftruncate() fails
> > > > > 
> > > > > Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
> > > > > ---
> > > > > v2: move this test to generic test and add comments why testcase
> > > > > use reflink.
> > > > Thanks for the updated version. Did it fail for you when testing on
> > > > unpatched kernel? I ran the test more than 10 times on 4.6 kernel (which
> > > > doesn't have the fix) and all passed, as well as RHEL7 kernel.
> > > > 
> > > > Can you please confirm?
> > > I tested this case in v4.6-rc7-162-g415b35a and it failed as expected,
> > > but I used the newest version btrfs-progs.
> > > In RHEL7.2ga, its btrfs-progs version is btrfs-progs-3.19.1-1.el7.x86_64,
> > > which is somewhat old. For small fs, it'll enable mixed mode for data and
> > > metadata default, so the reflink operation in this test case does not
> > > consume
> > > enough metadata, truncate operation can still succeed, then test will always
> > > pass. I can create a big fs to have test, but then this fs will have more
> > > metadata, which then need more reflink operations to consume metadata and
> > > increase the test time greatly.
> > > 
> > > In mkfs.btrfs manpage, there is such description：
> > >       versions up to 4.2.x forced the mixed mode for devices smaller
> > >       than 1GiB. This has been removed in 4.3+ as it caused some
> > >       usability issues.
> > I also tested on 4.6 kernel with v4.6 btrfs-progs, it passed 10+ times
> > without a fail. I was testing on a 4vcpu kvm guest with 8G memory,
> > TEST_DEV and SCRATCH_DEV are all 15G in size, not sure if that matters.
> Sorry, I run this test case in v4.6, it still failed.
> Would you please give me your kernel version and btrfs-progs version,
> like this format: v4.6-rc7-162-g415b35a, which is generated by "describe",
> then I can do some further investigation, thanks.

kernel v4.6 released version (tag v4.6), btrfs-progs "b9b0210 Btrfs progs
v4.6". Thanks for looking into this!

Eryu