| Message ID | 1499168434-23859-6-git-send-email-amir73il@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote: > Two tasks make a modification concurrently on two hardlinks of a large > lower inode. The copy up should be triggered by one of the tasks and the > other should be waiting for copy up to complete. Both copy up targets > should end up being upper hardlinks and both metadata changes should be > visible in both hardlinks. > > With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up So this will be fixed in 4.13-rc1 kernel? > is performed independetly and the resulting upper copy up targets each have > only one of the the metadata changes visible. > > Signed-off-by: Amir Goldstein <amir73il@gmail.com> > --- > tests/overlay/032 | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++ > tests/overlay/032.out | 4 ++ > tests/overlay/group | 1 + > 3 files changed, 107 insertions(+) > create mode 100755 tests/overlay/032 > create mode 100644 tests/overlay/032.out > > diff --git a/tests/overlay/032 b/tests/overlay/032 > new file mode 100755 > index 0000000..9a7995e > --- /dev/null > +++ b/tests/overlay/032 > @@ -0,0 +1,102 @@ > +#! /bin/bash > +# FS QA Test 032 > +# > +# Test concurrent copy up of lower hardlinks. > +# > +# Two tasks make a metadata change concurrently on two hardlinks of a large > +# lower inode. The copy up should be triggers by one of the tasks and the > +# other should be waiting for copy up to complete. Both copy up targets > +# should end up being upper hardlinks and both metadata changes should be > +# applied. > +# > +#----------------------------------------------------------------------- > +# Copyright (C) 2017 CTERA Networks. All Rights Reserved. > +# Author: Amir Goldstein <amir73il@gmail.com> > +# > +# 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() > +{ > + cd / > + rm -f $tmp.* > +} > + > +# get standard environment, filters and checks > +. ./common/rc > +. ./common/filter > + > +# remove previous $seqres.full before test > +rm -f $seqres.full > + > +# real QA test starts here > +_supported_fs overlay > +_supported_os Linux > +_require_scratch > + > +# Remove all files from previous tests > +_scratch_mkfs > + > +# overlay copy_up doesn't deal with sparse file well, holes will be filled by > +# zeros, so if both hardlinks are broken on copy up, we need (2*500M) free space > +# on $OVL_BASE_SCRATCH_MNT. > +_require_fs_space $OVL_BASE_SCRATCH_MNT $((500*1024*2)) > + > +# Create a large file in lower with 2 hardlinks > +lowerdir=$OVL_BASE_SCRATCH_MNT/$OVL_LOWER > +mkdir -p $lowerdir > +touch $lowerdir/zero > +$XFS_IO_PROG -c "truncate 500m" $lowerdir/zero > +ln $lowerdir/zero $lowerdir/one > +ln $lowerdir/zero $lowerdir/two > + > +_scratch_mount > + > +_do_cmd() I'd rename it to do_cmd for a local helper function. > +{ > + echo "`date +%T` $1..." >> $seqres.full > + eval "$1" > + echo "`date +%T` ...$1" >> $seqres.full > +} > + > +# Perform one modification on each hardlink (size and owner) > +_do_cmd "echo >> $SCRATCH_MNT/one" & > +# > +# When hardlinks are broken and overlayfs supports concurrent copy up, > +# $seqres.full will show that file two copy up started ~2s after file one > +# copy up started and ended ~2s after file one copy up ended. > +# With synchronized copy up of lower inodes, $seqres.full will show that > +# file two copy up ended at the same time as file one copy up. > +# > +sleep 2 If the first copyup finished within 2 seconds, it's not a concurrent modification on the two hardlinks. Does that break the test assumption? > +_do_cmd "chown 100 $SCRATCH_MNT/two" & > + > +wait > + > +# Expect all hardlinks to show both metadata modifications > +for f in zero one two; do > + _ls_l -n $SCRATCH_MNT/$f | awk '{ print $2, $3, $5, $9 }' | _filter_scratch Better to comment on what are the 4 fields. Thanks, Eryu > +done > + > +status=0 > +exit > diff --git a/tests/overlay/032.out b/tests/overlay/032.out > new file mode 100644 > index 0000000..0069740 > --- /dev/null > +++ b/tests/overlay/032.out > @@ -0,0 +1,4 @@ > +QA output created by 032 > +3 100 524288001 SCRATCH_MNT/zero > +3 100 524288001 SCRATCH_MNT/one > +3 100 524288001 SCRATCH_MNT/two > diff --git a/tests/overlay/group b/tests/overlay/group > index 28df5b6..2baba3a 100644 > --- a/tests/overlay/group > +++ b/tests/overlay/group > @@ -34,3 +34,4 @@ > 029 auto quick > 030 auto quick perms > 031 auto quick whiteout > +032 auto quick copyup hardlink > -- > 2.7.4 > -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 5, 2017 at 12:59 PM, Eryu Guan <eguan@redhat.com> wrote: > On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote: >> Two tasks make a modification concurrently on two hardlinks of a large >> lower inode. The copy up should be triggered by one of the tasks and the >> other should be waiting for copy up to complete. Both copy up targets >> should end up being upper hardlinks and both metadata changes should be >> visible in both hardlinks. >> >> With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up > > So this will be fixed in 4.13-rc1 kernel? It is fixed on current overlayfs-next branch. Yes. >> + >> +_do_cmd() > > I'd rename it to do_cmd for a local helper function. > sure >> +{ >> + echo "`date +%T` $1..." >> $seqres.full >> + eval "$1" >> + echo "`date +%T` ...$1" >> $seqres.full >> +} >> + >> +# Perform one modification on each hardlink (size and owner) >> +_do_cmd "echo >> $SCRATCH_MNT/one" & >> +# >> +# When hardlinks are broken and overlayfs supports concurrent copy up, >> +# $seqres.full will show that file two copy up started ~2s after file one >> +# copy up started and ended ~2s after file one copy up ended. >> +# With synchronized copy up of lower inodes, $seqres.full will show that >> +# file two copy up ended at the same time as file one copy up. >> +# >> +sleep 2 > > If the first copyup finished within 2 seconds, it's not a concurrent > modification on the two hardlinks. Does that break the test assumption? It will not be a race, plain 2 consequent copy ups, so not testing anything special, but won't cause test to fail. I am testing overlayfs with 2 underlying fs configurations: 1. xfs with clone support 2. ext4 With xfs clone up takes fraction of a second, the test is not really concurrent. With ext4, on my laptop with SSD, the 500M copy up takes ~3 seconds, which is quite close to the 2 seconds delay. I increased the copy up file size to 1G and now first copy up takes ~6 seconds, so there is more slack for the 2 sec delay, but still keeps the test 'quick'. > >> +_do_cmd "chown 100 $SCRATCH_MNT/two" & >> + >> +wait >> + >> +# Expect all hardlinks to show both metadata modifications >> +for f in zero one two; do >> + _ls_l -n $SCRATCH_MNT/$f | awk '{ print $2, $3, $5, $9 }' | _filter_scratch > > Better to comment on what are the 4 fields. > They show the metadata that was changes by chown and write. Will add a comment. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 05, 2017 at 01:46:51PM +0300, Amir Goldstein wrote: > On Wed, Jul 5, 2017 at 12:59 PM, Eryu Guan <eguan@redhat.com> wrote: > > On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote: > >> Two tasks make a modification concurrently on two hardlinks of a large > >> lower inode. The copy up should be triggered by one of the tasks and the > >> other should be waiting for copy up to complete. Both copy up targets > >> should end up being upper hardlinks and both metadata changes should be > >> visible in both hardlinks. > >> > >> With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up > > > > So this will be fixed in 4.13-rc1 kernel? > > It is fixed on current overlayfs-next branch. Yes. > > > >> + > >> +_do_cmd() > > > > I'd rename it to do_cmd for a local helper function. > > > > sure > > >> +{ > >> + echo "`date +%T` $1..." >> $seqres.full > >> + eval "$1" > >> + echo "`date +%T` ...$1" >> $seqres.full > >> +} > >> + > >> +# Perform one modification on each hardlink (size and owner) > >> +_do_cmd "echo >> $SCRATCH_MNT/one" & > >> +# > >> +# When hardlinks are broken and overlayfs supports concurrent copy up, > >> +# $seqres.full will show that file two copy up started ~2s after file one > >> +# copy up started and ended ~2s after file one copy up ended. > >> +# With synchronized copy up of lower inodes, $seqres.full will show that > >> +# file two copy up ended at the same time as file one copy up. > >> +# > >> +sleep 2 > > > > If the first copyup finished within 2 seconds, it's not a concurrent > > modification on the two hardlinks. Does that break the test assumption? > > It will not be a race, plain 2 consequent copy ups, so not testing anything > special, but won't cause test to fail. > > I am testing overlayfs with 2 underlying fs configurations: > 1. xfs with clone support > 2. ext4 > > With xfs clone up takes fraction of a second, the test is not really concurrent. > With ext4, on my laptop with SSD, the 500M copy up takes ~3 seconds, > which is quite close to the 2 seconds delay. > I increased the copy up file size to 1G and now first copy up takes ~6 seconds, > so there is more slack for the 2 sec delay, but still keeps the test 'quick'. Then what about don't sleep at all? So it doesn't rely on the copyup speed, the only drawback is the timestamps won't tell us more about the copyup behavior, but that doesn't seem critical to this test. But if sleep is still needed, some comments about it would be good. Thanks, Eryu > > > > >> +_do_cmd "chown 100 $SCRATCH_MNT/two" & > >> + > >> +wait > >> + > >> +# Expect all hardlinks to show both metadata modifications > >> +for f in zero one two; do > >> + _ls_l -n $SCRATCH_MNT/$f | awk '{ print $2, $3, $5, $9 }' | _filter_scratch > > > > Better to comment on what are the 4 fields. > > > > They show the metadata that was changes by chown and write. > Will add a comment. > > Thanks, > Amir. > -- > To unsubscribe from this list: send the line "unsubscribe fstests" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 5, 2017 at 2:32 PM, Eryu Guan <eguan@redhat.com> wrote: > On Wed, Jul 05, 2017 at 01:46:51PM +0300, Amir Goldstein wrote: >> On Wed, Jul 5, 2017 at 12:59 PM, Eryu Guan <eguan@redhat.com> wrote: >> > On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote: >> >> Two tasks make a modification concurrently on two hardlinks of a large >> >> lower inode. The copy up should be triggered by one of the tasks and the >> >> other should be waiting for copy up to complete. Both copy up targets >> >> should end up being upper hardlinks and both metadata changes should be >> >> visible in both hardlinks. >> >> >> >> With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up >> > >> > So this will be fixed in 4.13-rc1 kernel? >> >> It is fixed on current overlayfs-next branch. Yes. >> >> >> >> + >> >> +_do_cmd() >> > >> > I'd rename it to do_cmd for a local helper function. >> > >> >> sure >> >> >> +{ >> >> + echo "`date +%T` $1..." >> $seqres.full >> >> + eval "$1" >> >> + echo "`date +%T` ...$1" >> $seqres.full >> >> +} >> >> + >> >> +# Perform one modification on each hardlink (size and owner) >> >> +_do_cmd "echo >> $SCRATCH_MNT/one" & >> >> +# >> >> +# When hardlinks are broken and overlayfs supports concurrent copy up, >> >> +# $seqres.full will show that file two copy up started ~2s after file one >> >> +# copy up started and ended ~2s after file one copy up ended. >> >> +# With synchronized copy up of lower inodes, $seqres.full will show that >> >> +# file two copy up ended at the same time as file one copy up. >> >> +# >> >> +sleep 2 >> > >> > If the first copyup finished within 2 seconds, it's not a concurrent >> > modification on the two hardlinks. Does that break the test assumption? >> >> It will not be a race, plain 2 consequent copy ups, so not testing anything >> special, but won't cause test to fail. >> >> I am testing overlayfs with 2 underlying fs configurations: >> 1. xfs with clone support >> 2. ext4 >> >> With xfs clone up takes fraction of a second, the test is not really concurrent. >> With ext4, on my laptop with SSD, the 500M copy up takes ~3 seconds, >> which is quite close to the 2 seconds delay. >> I increased the copy up file size to 1G and now first copy up takes ~6 seconds, >> so there is more slack for the 2 sec delay, but still keeps the test 'quick'. > > Then what about don't sleep at all? So it doesn't rely on the copyup > speed, the only drawback is the timestamps won't tell us more about the > copyup behavior, but that doesn't seem critical to this test. > > But if sleep is still needed, some comments about it would be good. I'll go with comments. Thanks. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 5, 2017 at 1:46 PM, Amir Goldstein <amir73il@gmail.com> wrote: > On Wed, Jul 5, 2017 at 12:59 PM, Eryu Guan <eguan@redhat.com> wrote: >> On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote: >>> Two tasks make a modification concurrently on two hardlinks of a large >>> lower inode. The copy up should be triggered by one of the tasks and the >>> other should be waiting for copy up to complete. Both copy up targets >>> should end up being upper hardlinks and both metadata changes should be >>> visible in both hardlinks. >>> >>> With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up >> >> So this will be fixed in 4.13-rc1 kernel? > > It is fixed on current overlayfs-next branch. Yes. > Eryu, I realize that my answer was not accurate. These tests do pass with current overlayfs-next branch, but only with non default kernel config CONFIG_OVERLAY_FS_INDEX=y. This may be the right way to test, meaning that default kernel config reports failed tests related to hardlinks which are really broken on copy up with default kernel config. Another way to go at it is having these tests "_require_fs_module_param index" (CONFIG_OVERLAY_FS_INDEX sets the default of this parameter) and then opt-in to indexing in the test using the index=on mount option. This way, those test will notrun on old kernels and pass on new kernels regardless of the kernel config option. Then they will be testing that "hardlinks are not broken IF admin opts-in for indexing". I wonder which of the test methodologies you prefer. If you like the second one better I can send a patch to make those tests depend on and opt-in for indexing. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 11, 2017 at 11:23:50PM +0300, Amir Goldstein wrote: > On Wed, Jul 5, 2017 at 1:46 PM, Amir Goldstein <amir73il@gmail.com> wrote: > > On Wed, Jul 5, 2017 at 12:59 PM, Eryu Guan <eguan@redhat.com> wrote: > >> On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote: > >>> Two tasks make a modification concurrently on two hardlinks of a large > >>> lower inode. The copy up should be triggered by one of the tasks and the > >>> other should be waiting for copy up to complete. Both copy up targets > >>> should end up being upper hardlinks and both metadata changes should be > >>> visible in both hardlinks. > >>> > >>> With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up > >> > >> So this will be fixed in 4.13-rc1 kernel? > > > > It is fixed on current overlayfs-next branch. Yes. > > > > Eryu, > > I realize that my answer was not accurate. > These tests do pass with current overlayfs-next branch, but > only with non default kernel config CONFIG_OVERLAY_FS_INDEX=y. Thanks for the heads-up! > > This may be the right way to test, meaning that default kernel > config reports failed tests related to hardlinks which are really broken > on copy up with default kernel config. So these hardlink tests are still valid tests and the failures should be fixed eventually, even for OVERLAY_FS_INDEX=n kernels? If so, I think we can just keep the tests unchanged, just like all other tests that are targeting un-fixed bugs. Then the only issue is the commit log is not so accurate. Otherwise, I prefer your opt-in way, making these tests _notrun (assmuing they're not valid tests for this kernel config). Thanks, Eryu > > Another way to go at it is having these tests > "_require_fs_module_param index" (CONFIG_OVERLAY_FS_INDEX > sets the default of this parameter) and then opt-in to indexing in the test > using the index=on mount option. > > This way, those test will notrun on old kernels and pass > on new kernels regardless of the kernel config option. > Then they will be testing that "hardlinks are not broken IF > admin opts-in for indexing". > > I wonder which of the test methodologies you prefer. > If you like the second one better I can send a patch to make those > tests depend on and opt-in for indexing. > > Thanks, > Amir. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 12, 2017 at 6:17 AM, Eryu Guan <eguan@redhat.com> wrote: > On Tue, Jul 11, 2017 at 11:23:50PM +0300, Amir Goldstein wrote: >> On Wed, Jul 5, 2017 at 1:46 PM, Amir Goldstein <amir73il@gmail.com> wrote: >> > On Wed, Jul 5, 2017 at 12:59 PM, Eryu Guan <eguan@redhat.com> wrote: >> >> On Tue, Jul 04, 2017 at 02:40:32PM +0300, Amir Goldstein wrote: >> >>> Two tasks make a modification concurrently on two hardlinks of a large >> >>> lower inode. The copy up should be triggered by one of the tasks and the >> >>> other should be waiting for copy up to complete. Both copy up targets >> >>> should end up being upper hardlinks and both metadata changes should be >> >>> visible in both hardlinks. >> >>> >> >>> With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up >> >> >> >> So this will be fixed in 4.13-rc1 kernel? >> > >> > It is fixed on current overlayfs-next branch. Yes. >> > >> >> Eryu, >> >> I realize that my answer was not accurate. >> These tests do pass with current overlayfs-next branch, but >> only with non default kernel config CONFIG_OVERLAY_FS_INDEX=y. > > Thanks for the heads-up! > >> >> This may be the right way to test, meaning that default kernel >> config reports failed tests related to hardlinks which are really broken >> on copy up with default kernel config. > > So these hardlink tests are still valid tests and the failures should be > fixed eventually, even for OVERLAY_FS_INDEX=n kernels? If so, I think we The tests are valid anyway. hardlinks should not be broken when opened for write. This is why it might be best to leave the tests as is. But no, it will not be fixed for OVERLAY_FS_INDEX=n kernels and unlikely for kernel default to become OVERLAY_FS_INDEX=y. The way forward is for distros to change the their config to OVERLAY_FS_INDEX=y, but there is a downside for OVERLAY_FS_INDEX=y related to copying upper layers between file systems as described in [1]. So before distros can change the config to OVERLAY_FS_INDEX=y they need to make sure that no tool is migrating upper layers between file systems or copying within a file system. If such tools exist, then they should "export/import" the index while migrating layers (to fix the broken file handles) and said export/import tool does not exist yet. [1] https://github.com/amir73il/linux/commit/9412812ef54861081904f24ddaf176b957b98d40 > can just keep the tests unchanged, just like all other tests that are > targeting un-fixed bugs. Then the only issue is the commit log is not so > accurate. > > Otherwise, I prefer your opt-in way, making these tests _notrun > (assmuing they're not valid tests for this kernel config). So as I explained, they are valid, but not expected to be fixed by any change in upstream kernel, only a change in distro kernel config. I will post a patch to make them opt-in, because it will provide for much better test coverage of the new feature as long as the feature exists in tested kernel. Thanks. -- To unsubscribe from this list: send the line "unsubscribe fstests" 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/tests/overlay/032 b/tests/overlay/032 new file mode 100755 index 0000000..9a7995e --- /dev/null +++ b/tests/overlay/032 @@ -0,0 +1,102 @@ +#! /bin/bash +# FS QA Test 032 +# +# Test concurrent copy up of lower hardlinks. +# +# Two tasks make a metadata change concurrently on two hardlinks of a large +# lower inode. The copy up should be triggers by one of the tasks and the +# other should be waiting for copy up to complete. Both copy up targets +# should end up being upper hardlinks and both metadata changes should be +# applied. +# +#----------------------------------------------------------------------- +# Copyright (C) 2017 CTERA Networks. All Rights Reserved. +# Author: Amir Goldstein <amir73il@gmail.com> +# +# 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() +{ + cd / + rm -f $tmp.* +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter + +# remove previous $seqres.full before test +rm -f $seqres.full + +# real QA test starts here +_supported_fs overlay +_supported_os Linux +_require_scratch + +# Remove all files from previous tests +_scratch_mkfs + +# overlay copy_up doesn't deal with sparse file well, holes will be filled by +# zeros, so if both hardlinks are broken on copy up, we need (2*500M) free space +# on $OVL_BASE_SCRATCH_MNT. +_require_fs_space $OVL_BASE_SCRATCH_MNT $((500*1024*2)) + +# Create a large file in lower with 2 hardlinks +lowerdir=$OVL_BASE_SCRATCH_MNT/$OVL_LOWER +mkdir -p $lowerdir +touch $lowerdir/zero +$XFS_IO_PROG -c "truncate 500m" $lowerdir/zero +ln $lowerdir/zero $lowerdir/one +ln $lowerdir/zero $lowerdir/two + +_scratch_mount + +_do_cmd() +{ + echo "`date +%T` $1..." >> $seqres.full + eval "$1" + echo "`date +%T` ...$1" >> $seqres.full +} + +# Perform one modification on each hardlink (size and owner) +_do_cmd "echo >> $SCRATCH_MNT/one" & +# +# When hardlinks are broken and overlayfs supports concurrent copy up, +# $seqres.full will show that file two copy up started ~2s after file one +# copy up started and ended ~2s after file one copy up ended. +# With synchronized copy up of lower inodes, $seqres.full will show that +# file two copy up ended at the same time as file one copy up. +# +sleep 2 +_do_cmd "chown 100 $SCRATCH_MNT/two" & + +wait + +# Expect all hardlinks to show both metadata modifications +for f in zero one two; do + _ls_l -n $SCRATCH_MNT/$f | awk '{ print $2, $3, $5, $9 }' | _filter_scratch +done + +status=0 +exit diff --git a/tests/overlay/032.out b/tests/overlay/032.out new file mode 100644 index 0000000..0069740 --- /dev/null +++ b/tests/overlay/032.out @@ -0,0 +1,4 @@ +QA output created by 032 +3 100 524288001 SCRATCH_MNT/zero +3 100 524288001 SCRATCH_MNT/one +3 100 524288001 SCRATCH_MNT/two diff --git a/tests/overlay/group b/tests/overlay/group index 28df5b6..2baba3a 100644 --- a/tests/overlay/group +++ b/tests/overlay/group @@ -34,3 +34,4 @@ 029 auto quick 030 auto quick perms 031 auto quick whiteout +032 auto quick copyup hardlink
Two tasks make a modification concurrently on two hardlinks of a large lower inode. The copy up should be triggered by one of the tasks and the other should be waiting for copy up to complete. Both copy up targets should end up being upper hardlinks and both metadata changes should be visible in both hardlinks. With kernel <= v4.12, hardlinks are broken on copy up, meaning that copy up is performed independetly and the resulting upper copy up targets each have only one of the the metadata changes visible. Signed-off-by: Amir Goldstein <amir73il@gmail.com> --- tests/overlay/032 | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++ tests/overlay/032.out | 4 ++ tests/overlay/group | 1 + 3 files changed, 107 insertions(+) create mode 100755 tests/overlay/032 create mode 100644 tests/overlay/032.out