fstests: test btrfs fsync after hole punching with no-holes mode
PATCH 1/1 fstests: test btrfs fsync after hole punching with no-holes mode
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
--- tests/btrfs/159 | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/159.out | 5 +++ tests/btrfs/group | 1 + 3 files changed, 106 insertions(+) create mode 100755 tests/btrfs/159 create mode 100644 tests/btrfs/159.out
tests/btrfs/159 new file +100 -0
@@ -0,0 +1,100 @@ +#! /bin/bash +# FSQA Test No. 159 +# +# Test that when we have the no-holes mode enabled and a specific metadata +# layout, if we punch a hole and fsync the file, at replay time the whole +# hole was preserved. +# +#----------------------------------------------------------------------- +# +# Copyright (C) 2018 SUSE Linux Products GmbH. All Rights Reserved. +# Author: Filipe Manana <[email protected]> +# +# 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" +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + _cleanup_flakey + cd / + rm -f $tmp.* +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter +. ./common/dmflakey + +# real QA test starts here +_supported_fs generic +_supported_os Linux +_require_scratch +_require_dm_target flakey +_require_xfs_io_command "fpunch" + +rm -f $seqres.full + +# We create the filesystem with a node size of 64Kb because we need to create a +# specific metadata layout in order to trigger the bug we are testing. At the +# moment the node size can not be smaller then the system's page size, so given +# that the largest possible page size is 64Kb and by default the node size is +# set to the system's page size value, we explictly create a filesystem with a +# 64Kb node size. +_scratch_mkfs -O no-holes -n $((64 * 1024)) >>$seqres.full 2>&1 +_require_metadata_journaling $SCRATCH_DEV +_init_flakey +_mount_flakey + +# Create our test file with 831 extents of 256Kb each. Before each extent, there +# is a 256Kb hole (except for the first extent, which starts at offset 0). This +# creates two leafs in the filesystem tree, with the extent at offset 216530944 +# being the last item in the first leaf and the extent at offset 217055232 being +# the first item in the second leaf. +for ((i = 0; i <= 831; i++)); do + offset=$((i * 2 * 256 * 1024)) + $XFS_IO_PROG -f -c "pwrite -S 0xab -b 256K $offset 256K" \ + $SCRATCH_MNT/foobar >/dev/null +done + +# Now persist everything done so far. +sync + +# Now punch a hole that covers part of the extent at offset 216530944. +$XFS_IO_PROG -c "fpunch $((216530944 + 128 * 1024 - 4000)) 256K" \ + -c "fsync" \ + $SCRATCH_MNT/foobar + +echo "File digest before power failure:" +md5sum $SCRATCH_MNT/foobar | _filter_scratch + +# Simulate a power failure and mount the filesystem to check that replaying the +# fsync log/journal succeeds and our test file has the expected content. +_flakey_drop_and_remount + +echo "File digest after power failure and log replay:" +md5sum $SCRATCH_MNT/foobar | _filter_scratch + +_unmount_flakey +_cleanup_flakey + +status=0 +exit
tests/btrfs/159.out new file +5 -0
@@ -0,0 +1,5 @@ +QA output created by 159 +File digest before power failure: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +File digest after power failure and log replay: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar
tests/btrfs/group +1 -0
@@ -161,3 +161,4 @@ 156 auto quick trim 157 auto quick raid 158 auto quick raid scrub +159 auto quick
Signature · 1 line
2.11.0
Quoted 9 lines · On Mon, Mar 26, 2018 at 11:59:21PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix above is not there. But test always passes for me. Did I miss anything? btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
Quoted 54 lines
Signed-off-by Filipe Manana <[email protected]>--- tests/btrfs/159 | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/159.out | 5 +++ tests/btrfs/group | 1 + 3 files changed, 106 insertions(+) create mode 100755 tests/btrfs/159 create mode 100644 tests/btrfs/159.outtests/btrfs/159 new file +38
-0@@ -0,0 +1,100 @@ +#! /bin/bash +# FSQA Test No. 159 +# +# Test that when we have the no-holes mode enabled and a specific metadata +# layout, if we punch a hole and fsync the file, at replay time the whole +# hole was preserved. +# +#----------------------------------------------------------------------- +# +# Copyright (C) 2018 SUSE Linux Products GmbH. All Rights Reserved. +# Author: Filipe Manana <[email protected]> +# +# 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" +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + _cleanup_flakey + cd /
tests/btrfs/159 line 48
Quoted 10 lines
tests/btrfs/159 new file +10
-0+ rm -f $tmp.* +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter +. ./common/dmflakey + +# real QA test starts here +_supported_fs generic
^^^^^^^ btrfs
Quoted 9 lines
tests/btrfs/159 new file +9
-0+_supported_os Linux +_require_scratch +_require_dm_target flakey +_require_xfs_io_command "fpunch" + +rm -f $seqres.full + +# We create the filesystem with a node size of 64Kb because we need to create a +# specific metadata layout in order to trigger the bug we are testing. At the
tests/btrfs/159 line 67
Quoted 10 lines
tests/btrfs/159 new file +10
-0+# moment the node size can not be smaller then the system's page size, so given +# that the largest possible page size is 64Kb and by default the node size is +# set to the system's page size value, we explictly create a filesystem with a +# 64Kb node size. +_scratch_mkfs -O no-holes -n $((64 * 1024)) >>$seqres.full 2>&1 +_require_metadata_journaling $SCRATCH_DEV +_init_flakey +_mount_flakey + +# Create our test file with 831 extents of 256Kb each. Before each extent, there
I think it's 832 extents in total? As the index starts with 0.
Otherwise looks good to me.
Thanks,
Eryu
Quoted 60 lines
tests/btrfs/159 new file +33
-0+# is a 256Kb hole (except for the first extent, which starts at offset 0). This +# creates two leafs in the filesystem tree, with the extent at offset 216530944 +# being the last item in the first leaf and the extent at offset 217055232 being +# the first item in the second leaf. +for ((i = 0; i <= 831; i++)); do + offset=$((i * 2 * 256 * 1024)) + $XFS_IO_PROG -f -c "pwrite -S 0xab -b 256K $offset 256K" \ + $SCRATCH_MNT/foobar >/dev/null +done + +# Now persist everything done so far. +sync + +# Now punch a hole that covers part of the extent at offset 216530944. +$XFS_IO_PROG -c "fpunch $((216530944 + 128 * 1024 - 4000)) 256K" \ + -c "fsync" \ + $SCRATCH_MNT/foobar + +echo "File digest before power failure:" +md5sum $SCRATCH_MNT/foobar | _filter_scratch + +# Simulate a power failure and mount the filesystem to check that replaying the +# fsync log/journal succeeds and our test file has the expected content. +_flakey_drop_and_remount + +echo "File digest after power failure and log replay:" +md5sum $SCRATCH_MNT/foobar | _filter_scratch + +_unmount_flakey +_cleanup_flakey + +status=0 +exittests/btrfs/159.out new file +5
-0@@ -0,0 +1,5 @@ +QA output created by 159 +File digest before power failure: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +File digest after power failure and log replay: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobartests/btrfs/group +1
-0@@ -161,3 +161,4 @@ 156 auto quick trim 157 auto quick raid 158 auto quick raid scrub +159 auto quickSignature · 6 lines
2.11.0 -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · Eryu Guan
Quoted 6 lines · On Mon, Mar 26, 2018 at 11:59:21PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
Quoted 7 lines
Quoted 3 lines
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix above is not there. But test always passes for me. Did I miss anything? btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
It should fail on any kernel, with any btrfs-progs version (which should be irrelevant).
Somehow on your system we are not getting the specific metadata layout needed to trigger the issue.
Can you apply the following patch on top of the test and provide the result 159.full file?
https://friendpaste.com/6xAuLeN4xl1AGjO9Qc5I8L
So that I can see what metadata layout you are getting. Thanks!
Quoted 153 lines
Quoted 55 lines
Signed-off-by Filipe Manana <[email protected]>--- tests/btrfs/159 | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/159.out | 5 +++ tests/btrfs/group | 1 + 3 files changed, 106 insertions(+) create mode 100755 tests/btrfs/159 create mode 100644 tests/btrfs/159.outtests/btrfs/159 new file +38
-0@@ -0,0 +1,100 @@ +#! /bin/bash +# FSQA Test No. 159 +# +# Test that when we have the no-holes mode enabled and a specific metadata +# layout, if we punch a hole and fsync the file, at replay time the whole +# hole was preserved. +# +#----------------------------------------------------------------------- +# +# Copyright (C) 2018 SUSE Linux Products GmbH. All Rights Reserved. +# Author: Filipe Manana <[email protected]> +# +# 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" +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + _cleanup_flakey + cd /tests/btrfs/159 line 48
Quoted 10 lines
tests/btrfs/159 new file +10
-0+ rm -f $tmp.* +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter +. ./common/dmflakey + +# real QA test starts here +_supported_fs generic^^^^^^^ btrfsQuoted 9 lines
tests/btrfs/159 new file +9
-0+_supported_os Linux +_require_scratch +_require_dm_target flakey +_require_xfs_io_command "fpunch" + +rm -f $seqres.full + +# We create the filesystem with a node size of 64Kb because we need to create a +# specific metadata layout in order to trigger the bug we are testing. At thetests/btrfs/159 line 67
Quoted 10 lines
tests/btrfs/159 new file +10
-0+# moment the node size can not be smaller then the system's page size, so given +# that the largest possible page size is 64Kb and by default the node size is +# set to the system's page size value, we explictly create a filesystem with a +# 64Kb node size. +_scratch_mkfs -O no-holes -n $((64 * 1024)) >>$seqres.full 2>&1 +_require_metadata_journaling $SCRATCH_DEV +_init_flakey +_mount_flakey + +# Create our test file with 831 extents of 256Kb each. Before each extent, thereI think it's 832 extents in total? As the index starts with 0.
Otherwise looks good to me.
Thanks,
EryuQuoted 60 lines
tests/btrfs/159 new file +33
-0+# is a 256Kb hole (except for the first extent, which starts at offset 0). This +# creates two leafs in the filesystem tree, with the extent at offset 216530944 +# being the last item in the first leaf and the extent at offset 217055232 being +# the first item in the second leaf. +for ((i = 0; i <= 831; i++)); do + offset=$((i * 2 * 256 * 1024)) + $XFS_IO_PROG -f -c "pwrite -S 0xab -b 256K $offset 256K" \ + $SCRATCH_MNT/foobar >/dev/null +done + +# Now persist everything done so far. +sync + +# Now punch a hole that covers part of the extent at offset 216530944. +$XFS_IO_PROG -c "fpunch $((216530944 + 128 * 1024 - 4000)) 256K" \ + -c "fsync" \ + $SCRATCH_MNT/foobar + +echo "File digest before power failure:" +md5sum $SCRATCH_MNT/foobar | _filter_scratch + +# Simulate a power failure and mount the filesystem to check that replaying the +# fsync log/journal succeeds and our test file has the expected content. +_flakey_drop_and_remount + +echo "File digest after power failure and log replay:" +md5sum $SCRATCH_MNT/foobar | _filter_scratch + +_unmount_flakey +_cleanup_flakey + +status=0 +exittests/btrfs/159.out new file +5
-0@@ -0,0 +1,5 @@ +QA output created by 159 +File digest before power failure: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +File digest after power failure and log replay: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobartests/btrfs/group +1
-1@@ -161,3 +161,4 @@ 156 auto quick trim 157 auto quick raid 158 auto quick raid scrub +159 auto quick --2.11.0
--
To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 21 lines · Filipe Manana
Quoted 7 lines · Eryu Guan
Quoted 6 lines · On Mon, Mar 26, 2018 at 11:59:21PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
Quoted 7 lines
Quoted 3 lines
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix above is not there. But test always passes for me. Did I miss anything? btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
It should fail on any kernel, with any btrfs-progs version (which should be irrelevant).
Somehow on your system we are not getting the specific metadata layout needed to trigger the issue.
Quoted 7 lines
Can you apply the following patch on top of the test and provide the result 159.full file?
https://friendpaste.com/6xAuLeN4xl1AGjO9Qc5I8L
So that I can see what metadata layout you are getting. Thanks!
Sure, please see attachment.
Thanks,
Eryu
Quoted 25 lines · Eryu Guan
Quoted 24 lines · Filipe Manana
Quoted 7 lines · Eryu Guan
Quoted 6 lines · On Mon, Mar 26, 2018 at 11:59:21PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
Quoted 7 lines
Quoted 3 lines
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix above is not there. But test always passes for me. Did I miss anything? btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
It should fail on any kernel, with any btrfs-progs version (which should be irrelevant).
Somehow on your system we are not getting the specific metadata layout needed to trigger the issue.Can you apply the following patch on top of the test and provide the result 159.full file?
Quoted 6 lines
Quoted 4 lines
https://friendpaste.com/6xAuLeN4xl1AGjO9Qc5I8L
So that I can see what metadata layout you are getting. Thanks!
Sure, please see attachment.
Thanks!
So you indeed get a different metadata layout, and that is because you have SELinux enabled which causes some xattr to be added to the test file (foobar):
item 6 key (257 XATTR_ITEM 3817753667) itemoff 64932 itemsize 83
location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 37 name_len 16
name: security.selinux
data unconfined_u:object_r:unlabeled_t:s0
I can make the test work with and without selinux enabled (by punching holes on a few extents that are candidates to be at leaf boundaries). Is it worth it? (I assume most people run the tests without selinux)
thanks
Quoted 3 lines
Thanks,
Eryu
Hi Filipe,
I tried running the xfstest above on kernel 4.15.0 and I haven't been able to hit the bug. The xfstest passes clean for me. I compared the btrfs-debug-tree in my case with the one attached by Eryu, and I see I do not have any xattr as he does. However, for every run of the xfstest, the extent tree info that I get from btrfs-debug-tree has varying number of items in the first leaf node. (I have attached two dump files for your reference.)
I also tried changing the offset at which fpunch is performed to match the offset of the last extent in the first leaf of the extent tree - however the md5 before and after crash was the same.
Could you give more details on this?
https://friendpaste.com/1wVAz7hG0U5SgYtZavbJhL
https://friendpaste.com/1wVAz7hG0U5SgYtZavxALg
Thanks,
Jayashree Mohan
Quoted 57 lines · Filipe Manana
Quoted 25 lines · Eryu Guan
Quoted 24 lines · Filipe Manana
Quoted 7 lines · Eryu Guan
Quoted 6 lines · On Mon, Mar 26, 2018 at 11:59:21PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
Quoted 7 lines
Quoted 3 lines
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix above is not there. But test always passes for me. Did I miss anything? btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
It should fail on any kernel, with any btrfs-progs version (which should be irrelevant).
Somehow on your system we are not getting the specific metadata layout needed to trigger the issue.Can you apply the following patch on top of the test and provide the result 159.full file?
Quoted 6 lines
Quoted 4 lines
https://friendpaste.com/6xAuLeN4xl1AGjO9Qc5I8L
So that I can see what metadata layout you are getting. Thanks!
Sure, please see attachment.
Thanks!
So you indeed get a different metadata layout, and that is because you have SELinux enabled which causes some xattr to be added to the test file (foobar):item 6 key (257
XATTR_ITEM3817753667) itemoff 64932 itemsize 83
location key (0 UNKNOWN.0 0) type XATTR transid 7data_len37name_len16
name: security.selinux
data unconfined_u:object_r:unlabeled_t:s0I can make the test work with and without selinux enabled (by punching holes on a few extents that are candidates to be at leaf boundaries). Is it worth it? (I assume most people run the tests without selinux)
thanks
Quoted 3 lines
Thanks,
Eryu--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · Jayashree Mohan
Hi Filipe,
I tried running the xfstest above on kernel 4.15.0 and I haven't been able to hit the bug. The xfstest passes clean for me. I compared the btrfs-debug-tree in my case with the one attached by Eryu, and I see I do not have any xattr as he does. However, for every run of the xfstest, the extent tree info that I get from btrfs-debug-tree has varying number of items in the first leaf node. (I have attached two dump files for your reference.)
Quoted 5 lines
I also tried changing the offset at which fpunch is performed to match the offset of the last extent in the first leaf of the extent tree - however the md5 before and after crash was the same.
Could you give more details on this?
You are getting extents smaller then 256Kb, because writeback is being triggered by the kernel (likely due to memory pressure). The second version of the test uses direct IO instead to avoid that. Thanks.
Quoted 67 lines
https://friendpaste.com/1wVAz7hG0U5SgYtZavbJhL
https://friendpaste.com/1wVAz7hG0U5SgYtZavxALgThanks,
Jayashree MohanQuoted 57 lines · Filipe Manana
Quoted 25 lines · Eryu Guan
Quoted 24 lines · Filipe Manana
Quoted 7 lines · Eryu Guan
Quoted 6 lines · On Mon, Mar 26, 2018 at 11:59:21PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
Quoted 7 lines
Quoted 3 lines
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix above is not there. But test always passes for me. Did I miss anything? btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
It should fail on any kernel, with any btrfs-progs version (which should be irrelevant).
Somehow on your system we are not getting the specific metadata layout needed to trigger the issue.Can you apply the following patch on top of the test and provide the result 159.full file?
Quoted 6 lines
Quoted 4 lines
https://friendpaste.com/6xAuLeN4xl1AGjO9Qc5I8L
So that I can see what metadata layout you are getting. Thanks!
Sure, please see attachment.
Thanks!
So you indeed get a different metadata layout, and that is because you have SELinux enabled which causes some xattr to be added to the test file (foobar):item 6 key (257
XATTR_ITEM3817753667) itemoff 64932 itemsize 83
location key (0 UNKNOWN.0 0) type XATTR transid 7data_len37name_len16
name: security.selinux
data unconfined_u:object_r:unlabeled_t:s0I can make the test work with and without selinux enabled (by punching holes on a few extents that are candidates to be at leaf boundaries). Is it worth it? (I assume most people run the tests without selinux)
thanks
Quoted 3 lines
Thanks,
Eryu--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · Filipe Manana
Quoted 14 lines · Jayashree Mohan
Hi Filipe,
I tried running the xfstest above on kernel 4.15.0 and I haven't been able to hit the bug. The xfstest passes clean for me. I compared the btrfs-debug-tree in my case with the one attached by Eryu, and I see I do not have any xattr as he does. However, for every run of the xfstest, the extent tree info that I get from btrfs-debug-tree has varying number of items in the first leaf node. (I have attached two dump files for your reference.)
I also tried changing the offset at which fpunch is performed to match the offset of the last extent in the first leaf of the extent tree - however the md5 before and after crash was the same.
Quoted 6 lines
Quoted 1 line
Could you give more details on this?
You are getting extents smaller then 256Kb, because writeback is being triggered by the kernel (likely due to memory pressure). The second version of the test uses direct IO instead to avoid that. Thanks.
Thanks for the clarification. I am able to reproduce the bug with the new version of the test that uses direct writes.
Quoted 44 lines · Filipe Manana
Quoted 25 lines · Eryu Guan
Quoted 24 lines · Filipe Manana
Quoted 7 lines · Eryu Guan
Quoted 6 lines · On Mon, Mar 26, 2018 at 11:59:21PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
Quoted 7 lines
Quoted 3 lines
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix above is not there. But test always passes for me. Did I miss anything? btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
It should fail on any kernel, with any btrfs-progs version (which should be irrelevant).
Somehow on your system we are not getting the specific metadata layout needed to trigger the issue.Can you apply the following patch on top of the test and provide the result 159.full file?
Quoted 6 lines
Quoted 4 lines
https://friendpaste.com/6xAuLeN4xl1AGjO9Qc5I8L
So that I can see what metadata layout you are getting. Thanks!
Sure, please see attachment.
Thanks!
So you indeed get a different metadata layout, and that is because you have SELinux enabled which causes some xattr to be added to the test file (foobar):item 6 key (257
XATTR_ITEM3817753667) itemoff 64932 itemsize 83
location key (0 UNKNOWN.0 0) type XATTR transid 7data_len37name_len16
name: security.selinux
data unconfined_u:object_r:unlabeled_t:s0
Quoted 3 lines
I can make the test work with and without selinux enabled (by punching holes on a few extents that are candidates to be at leaf boundaries). Is it worth it? (I assume most people run the tests without selinux)
Yes, please make it work with selinux if possible (but if that requires too much complexity, we can give it a second thought).
I'm not sure about others, but I run fstests with selinux almost all the time, because Fedora/RHEL distros have selinux on by default :) so are all other people using Fedora/RHEL/Centos as test hosts, I guess.
Thanks,
Eryu
PATCH v2 1/1 fstests: test btrfs fsync after hole punching with no-holes mode
In reply to [email protected]From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
---
V2: Made the test work when selinux is enabled, and made it use direct IO
writes to ensure 256K extents.
tests/btrfs/159 | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/159.out | 9 ++++ tests/btrfs/group | 1 + 3 files changed, 125 insertions(+) create mode 100755 tests/btrfs/159 create mode 100644 tests/btrfs/159.out
tests/btrfs/159 new file +115 -0
@@ -0,0 +1,115 @@ +#! /bin/bash +# FSQA Test No. 159 +# +# Test that when we have the no-holes mode enabled and a specific metadata +# layout, if we punch a hole and fsync the file, at replay time the whole +# hole was preserved. +# +#----------------------------------------------------------------------- +# +# Copyright (C) 2018 SUSE Linux Products GmbH. All Rights Reserved. +# Author: Filipe Manana <[email protected]> +# +# 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" +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + _cleanup_flakey + cd / + rm -f $tmp.* +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter +. ./common/dmflakey + +# real QA test starts here +_supported_fs btrfs +_supported_os Linux +_require_scratch +_require_dm_target flakey +_require_xfs_io_command "fpunch" +_require_odirect + +rm -f $seqres.full + +run_test() +{ + local punch_offset=$1 + + # We create the filesystem with a node size of 64Kb because we need to + # create a specific metadata layout in order to trigger the bug we are + # testing. At the moment the node size can not be smaller then the + # system's page size, so given that the largest possible page size is + # 64Kb and by default the node size is set to the system's page size + # value, we explicitly create a filesystem with a 64Kb node size. + _scratch_mkfs -O no-holes -n $((64 * 1024)) >>$seqres.full 2>&1 + _require_metadata_journaling $SCRATCH_DEV + _init_flakey + _mount_flakey + + # Create our test file with 832 extents of 256Kb each. Before each + # extent, there is a 256Kb hole (except for the first extent, which + # starts at offset 0). This creates two leafs in the filesystem tree. + # We use direct IO to ensure we get exactly 256K extents (with buffered + # IO we can get writeback triggered at any time and therefore get + # extents smaller than 256K). + for ((i = 0; i <= 831; i++)); do + local offset=$((i * 2 * 256 * 1024)) + $XFS_IO_PROG -f -d -c "pwrite -S 0xab -b 256K $offset 256K" \ + $SCRATCH_MNT/foobar >/dev/null + done + + # Make sure everything done so far is durably persisted. + sync + + # Now punch a hole that covers part of the extent at offset + # "$punch_offset". + # We want to punch a hole that starts in the middle of the last extent + # item in the first leaf. On a system without selinux enabled that is + # the extent that starts at offset 216530944, while on a system with it + # enabled it is the extent that starts at offset 216006656 (because + # selinux causes a xattr item to be added to our test file). + $XFS_IO_PROG -c "fpunch $((punch_offset + 128 * 1024 - 4000)) 256K" \ + -c "fsync" \ + $SCRATCH_MNT/foobar + + echo "File digest before power failure:" + md5sum $SCRATCH_MNT/foobar | _filter_scratch + # Simulate a power failure and mount the filesystem to check that + # replaying the fsync log/journal succeeds and our test file has the + # expected content. + _flakey_drop_and_remount + echo "File digest after power failure and log replay:" + md5sum $SCRATCH_MNT/foobar | _filter_scratch + + _unmount_flakey + _cleanup_flakey +} + +run_test 216006656 +run_test 216530944 + +status=0 +exit
tests/btrfs/159.out new file +9 -0
@@ -0,0 +1,9 @@ +QA output created by 159 +File digest before power failure: +f049865ed45b1991dc9a299b47d51dbf SCRATCH_MNT/foobar +File digest after power failure and log replay: +f049865ed45b1991dc9a299b47d51dbf SCRATCH_MNT/foobar +File digest before power failure: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +File digest after power failure and log replay: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar
tests/btrfs/group +1 -0
@@ -161,3 +161,4 @@ 156 auto quick trim 157 auto quick raid 158 auto quick raid scrub +159 auto quick
Signature · 1 line
2.11.0
Quoted 8 lines · On Wed, Mar 28, 2018 at 12:55:30PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
Quoted 7 lines
"Btrfs: fix fsync after hole punching when using no-holes feature"
Signed-off-by Filipe Manana <[email protected]>---
V2: Made the test work when selinux is enabled, and made it use direct IO
writes to ensure 256K extents.
Test fails with selinux enabled now on unpatched kernel. But I found that, in my release testing, test still fails when testing with current Linus tree (HEAD is 642e7fd23353, without selinux this time), which should contain the mentioned fix. Does that mean the bug is not fully fixed?
root/xfstests/results//btrfs/159.out.bad 2018-04-08 00:28:26.921968949 -0700 renamed from btrfs/159.out 2018-04-03 18:25:41.566105514 -0700 +1 -1
@@ -6,4 +6,4 @@ File digest before power failure: c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar File digest after power failure and log replay: -c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +c84746bbd1b97420f076d417a6a7d81c SCRATCH_MNT/foobar
I'll drop this patch for now.
Thanks,
Eryu
Quoted 160 lines
tests/btrfs/159 | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/159.out | 9 ++++ tests/btrfs/group | 1 + 3 files changed, 125 insertions(+) create mode 100755 tests/btrfs/159 create mode 100644 tests/btrfs/159.outtests/btrfs/159 new file +115
-0@@ -0,0 +1,115 @@ +#! /bin/bash +# FSQA Test No. 159 +# +# Test that when we have the no-holes mode enabled and a specific metadata +# layout, if we punch a hole and fsync the file, at replay time the whole +# hole was preserved. +# +#----------------------------------------------------------------------- +# +# Copyright (C) 2018 SUSE Linux Products GmbH. All Rights Reserved. +# Author: Filipe Manana <[email protected]> +# +# 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" +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + _cleanup_flakey + cd / + rm -f $tmp.* +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter +. ./common/dmflakey + +# real QA test starts here +_supported_fs btrfs +_supported_os Linux +_require_scratch +_require_dm_target flakey +_require_xfs_io_command "fpunch" +_require_odirect + +rm -f $seqres.full + +run_test() +{ + local punch_offset=$1 + + # We create the filesystem with a node size of 64Kb because we need to + # create a specific metadata layout in order to trigger the bug we are + # testing. At the moment the node size can not be smaller then the + # system's page size, so given that the largest possible page size is + # 64Kb and by default the node size is set to the system's page size + # value, we explicitly create a filesystem with a 64Kb node size. + _scratch_mkfs -O no-holes -n $((64 * 1024)) >>$seqres.full 2>&1 + _require_metadata_journaling $SCRATCH_DEV + _init_flakey + _mount_flakey + + # Create our test file with 832 extents of 256Kb each. Before each + # extent, there is a 256Kb hole (except for the first extent, which + # starts at offset 0). This creates two leafs in the filesystem tree. + # We use direct IO to ensure we get exactly 256K extents (with buffered + # IO we can get writeback triggered at any time and therefore get + # extents smaller than 256K). + for ((i = 0; i <= 831; i++)); do + local offset=$((i * 2 * 256 * 1024)) + $XFS_IO_PROG -f -d -c "pwrite -S 0xab -b 256K $offset 256K" \ + $SCRATCH_MNT/foobar >/dev/null + done + + # Make sure everything done so far is durably persisted. + sync + + # Now punch a hole that covers part of the extent at offset + # "$punch_offset". + # We want to punch a hole that starts in the middle of the last extent + # item in the first leaf. On a system without selinux enabled that is + # the extent that starts at offset 216530944, while on a system with it + # enabled it is the extent that starts at offset 216006656 (because + # selinux causes a xattr item to be added to our test file). + $XFS_IO_PROG -c "fpunch $((punch_offset + 128 * 1024 - 4000)) 256K" \ + -c "fsync" \ + $SCRATCH_MNT/foobar + + echo "File digest before power failure:" + md5sum $SCRATCH_MNT/foobar | _filter_scratch + # Simulate a power failure and mount the filesystem to check that + # replaying the fsync log/journal succeeds and our test file has the + # expected content. + _flakey_drop_and_remount + echo "File digest after power failure and log replay:" + md5sum $SCRATCH_MNT/foobar | _filter_scratch + + _unmount_flakey + _cleanup_flakey +} + +run_test 216006656 +run_test 216530944 + +status=0 +exittests/btrfs/159.out new file +9
-0@@ -0,0 +1,9 @@ +QA output created by 159 +File digest before power failure: +f049865ed45b1991dc9a299b47d51dbf SCRATCH_MNT/foobar +File digest after power failure and log replay: +f049865ed45b1991dc9a299b47d51dbf SCRATCH_MNT/foobar +File digest before power failure: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +File digest after power failure and log replay: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobartests/btrfs/group +1
-0@@ -161,3 +161,4 @@ 156 auto quick trim 157 auto quick raid 158 auto quick raid scrub +159 auto quickSignature · 6 lines
2.11.0 -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 14 lines · Eryu Guan
Quoted 13 lines · On Wed, Mar 28, 2018 at 12:55:30PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
Signed-off-by Filipe Manana <[email protected]>---
Quoted 8 lines
Quoted 2 lines
V2: Made the test work when selinux is enabled, and made it use direct IO
writes to ensure 256K extents.Test fails with selinux enabled now on unpatched kernel. But I found that, in my release testing, test still fails when testing with current Linus tree (HEAD is
642e7fd23353, without selinux this time), which should contain the mentioned fix. Does that mean the bug is not fully fixed?
The bug is fully fixed. But HEAD 642e7fd23353 does not contain the fix. The current linus' master has it.
Quoted 175 lines
root/xfstests/results//btrfs/159.out.bad 2018-04-08 00:28:26.921968949 -0700 renamed from btrfs/159.out 2018-04-03 18:25:41.566105514 -0700 +1
-1@@ -6,4 +6,4 @@ File digest before power failure: c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar File digest after power failure and log replay: -c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +c84746bbd1b97420f076d417a6a7d81c SCRATCH_MNT/foobarI'll drop this patch for now.
Thanks,
EryuQuoted 160 lines
tests/btrfs/159 | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/159.out | 9 ++++ tests/btrfs/group | 1 + 3 files changed, 125 insertions(+) create mode 100755 tests/btrfs/159 create mode 100644 tests/btrfs/159.outtests/btrfs/159 new file +115
-0@@ -0,0 +1,115 @@ +#! /bin/bash +# FSQA Test No. 159 +# +# Test that when we have the no-holes mode enabled and a specific metadata +# layout, if we punch a hole and fsync the file, at replay time the whole +# hole was preserved. +# +#----------------------------------------------------------------------- +# +# Copyright (C) 2018 SUSE Linux Products GmbH. All Rights Reserved. +# Author: Filipe Manana <[email protected]> +# +# 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" +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + _cleanup_flakey + cd / + rm -f $tmp.* +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter +. ./common/dmflakey + +# real QA test starts here +_supported_fs btrfs +_supported_os Linux +_require_scratch +_require_dm_target flakey +_require_xfs_io_command "fpunch" +_require_odirect + +rm -f $seqres.full + +run_test() +{ + local punch_offset=$1 + + # We create the filesystem with a node size of 64Kb because we need to + # create a specific metadata layout in order to trigger the bug we are + # testing. At the moment the node size can not be smaller then the + # system's page size, so given that the largest possible page size is + # 64Kb and by default the node size is set to the system's page size + # value, we explicitly create a filesystem with a 64Kb node size. + _scratch_mkfs -O no-holes -n $((64 * 1024)) >>$seqres.full 2>&1 + _require_metadata_journaling $SCRATCH_DEV + _init_flakey + _mount_flakey + + # Create our test file with 832 extents of 256Kb each. Before each + # extent, there is a 256Kb hole (except for the first extent, which + # starts at offset 0). This creates two leafs in the filesystem tree. + # We use direct IO to ensure we get exactly 256K extents (with buffered + # IO we can get writeback triggered at any time and therefore get + # extents smaller than 256K). + for ((i = 0; i <= 831; i++)); do + local offset=$((i * 2 * 256 * 1024)) + $XFS_IO_PROG -f -d -c "pwrite -S 0xab -b 256K $offset 256K" \ + $SCRATCH_MNT/foobar >/dev/null + done + + # Make sure everything done so far is durably persisted. + sync + + # Now punch a hole that covers part of the extent at offset + # "$punch_offset". + # We want to punch a hole that starts in the middle of the last extent + # item in the first leaf. On a system without selinux enabled that is + # the extent that starts at offset 216530944, while on a system with it + # enabled it is the extent that starts at offset 216006656 (because + # selinux causes a xattr item to be added to our test file). + $XFS_IO_PROG -c "fpunch $((punch_offset + 128 * 1024 - 4000)) 256K" \ + -c "fsync" \ + $SCRATCH_MNT/foobar + + echo "File digest before power failure:" + md5sum $SCRATCH_MNT/foobar | _filter_scratch + # Simulate a power failure and mount the filesystem to check that + # replaying the fsync log/journal succeeds and our test file has the + # expected content. + _flakey_drop_and_remount + echo "File digest after power failure and log replay:" + md5sum $SCRATCH_MNT/foobar | _filter_scratch + + _unmount_flakey + _cleanup_flakey +} + +run_test 216006656 +run_test 216530944 + +status=0 +exittests/btrfs/159.out new file +9
-0@@ -0,0 +1,9 @@ +QA output created by 159 +File digest before power failure: +f049865ed45b1991dc9a299b47d51dbf SCRATCH_MNT/foobar +File digest after power failure and log replay: +f049865ed45b1991dc9a299b47d51dbf SCRATCH_MNT/foobar +File digest before power failure: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobar +File digest after power failure and log replay: +c5c0a13588a639529c979c57c336f441 SCRATCH_MNT/foobartests/btrfs/group +1
-1@@ -161,3 +161,4 @@ 156 auto quick trim 157 auto quick raid 158 auto quick raid scrub +159 auto quick --2.11.0
--
To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 18 lines · Filipe Manana
Quoted 17 lines · Eryu Guan
Quoted 15 lines · On Wed, Mar 28, 2018 at 12:55:30PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
Signed-off-by Filipe Manana <[email protected]>---
V2: Made the test work when selinux is enabled, and made it use direct IO
writes to ensure 256K extents.
Quoted 8 lines
Quoted 5 lines
Test fails with selinux enabled now on unpatched kernel. But I found that, in my release testing, test still fails when testing with current Linus tree (HEAD is
642e7fd23353, without selinux this time), which should contain the mentioned fix. Does that mean the bug is not fully fixed?The bug is fully fixed. But HEAD
642e7fd23353does not contain the fix. The current linus' master has it.
I'll double check.. Thanks for the heads-up!
Eryu
Quoted 25 lines · Eryu Guan
Quoted 24 lines · Filipe Manana
Quoted 22 lines · Eryu Guan
Quoted 8 lines · On Wed, Mar 28, 2018 at 12:55:30PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
Quoted 7 lines
"Btrfs: fix fsync after hole punching when using no-holes feature"
Signed-off-by Filipe Manana <[email protected]>---
V2: Made the test work when selinux is enabled, and made it use direct IO
writes to ensure 256K extents.Test fails with selinux enabled now on unpatched kernel. But I found that, in my release testing, test still fails when testing with current Linus tree (HEAD is
642e7fd23353, without selinux this time), which should contain the mentioned fix. Does that mean the bug is not fully fixed?
Quoted 4 lines
Quoted 2 lines
The bug is fully fixed. But HEAD
642e7fd23353does not contain the fix. The current linus' master has it.I'll double check.. Thanks for the heads-up!
Hi Eryu, any reason this didn't go in the last update? Thanks.
Quoted 2 lines
Eryu
Quoted 26 lines · Filipe Manana
Quoted 25 lines · Eryu Guan
Quoted 24 lines · Filipe Manana
Quoted 22 lines · Eryu Guan
Quoted 8 lines · On Wed, Mar 28, 2018 at 12:55:30PM +0100, [email protected] wrote:
From: Filipe Manana <[email protected]>
Test that when we have the no-holes mode enabled and a specific metadata layout, if we punch a hole and fsync the file, at replay time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
Quoted 7 lines
"Btrfs: fix fsync after hole punching when using no-holes feature"
Signed-off-by Filipe Manana <[email protected]>---
V2: Made the test work when selinux is enabled, and made it use direct IO
writes to ensure 256K extents.Test fails with selinux enabled now on unpatched kernel. But I found that, in my release testing, test still fails when testing with current Linus tree (HEAD is
642e7fd23353, without selinux this time), which should contain the mentioned fix. Does that mean the bug is not fully fixed?
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
The bug is fully fixed. But HEAD
642e7fd23353does not contain the fix. The current linus' master has it.I'll double check.. Thanks for the heads-up!
Hi Eryu, any reason this didn't go in the last update? Thanks.
Sorry, I thought I queued it for last update, but actually I queued "generic: test for fsync after fallocate" not this one (and I double checked that test not this one..). I'll give it another try and queue it for next update if all look well.
Thanks,
Eryu