* [PATCH] generic/520: use fsync instead of sync during clean_dir @ 2019-12-13 5:45 Yang Xu 2019-12-13 20:42 ` Darrick J. Wong 2019-12-20 12:32 ` Filipe Manana 0 siblings, 2 replies; 9+ messages in thread From: Yang Xu @ 2019-12-13 5:45 UTC (permalink / raw) To: fstests; +Cc: Yang Xu When I test this case on xfs, it may fail as below: -------------------------------------------- === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === +umount: /mnt/xfstests/scratch: target is busy. + (In some cases useful info about processes that use + the device is found by lsof(8) or fuser(1)) --------------------------------------------- I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> --- tests/generic/520 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/generic/520 b/tests/generic/520 index 167d7077..a16467ca 100755 --- a/tests/generic/520 +++ b/tests/generic/520 @@ -58,7 +58,7 @@ clean_dir() { _mount_flakey rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") - sync + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT _unmount_flakey } -- 2.18.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-13 5:45 [PATCH] generic/520: use fsync instead of sync during clean_dir Yang Xu @ 2019-12-13 20:42 ` Darrick J. Wong 2019-12-16 6:24 ` Yang Xu 2019-12-20 12:32 ` Filipe Manana 1 sibling, 1 reply; 9+ messages in thread From: Darrick J. Wong @ 2019-12-13 20:42 UTC (permalink / raw) To: Yang Xu; +Cc: fstests On Fri, Dec 13, 2019 at 01:45:41PM +0800, Yang Xu wrote: > When I test this case on xfs, it may fail as below: > -------------------------------------------- > === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === > +umount: /mnt/xfstests/scratch: target is busy. > + (In some cases useful info about processes that use > + the device is found by lsof(8) or fuser(1)) > --------------------------------------------- > > I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. > > Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> > --- > tests/generic/520 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/generic/520 b/tests/generic/520 > index 167d7077..a16467ca 100755 > --- a/tests/generic/520 > +++ b/tests/generic/520 > @@ -58,7 +58,7 @@ clean_dir() > { > _mount_flakey > rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") > - sync > + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT But that only has to force the scratch mount directory to disk. Assuming the test authors really meant "write all of the scratch fs' dirty data/metadata to disk", I think you want: $XFS_IO_PROG -c syncfs $SCRATCH_MNT here? Also, why did umount spit out 'target is busy' here? clean_dir() erases the scratch fs between tests, there shouldn't be anything flakey about that. --D > _unmount_flakey > } > > -- > 2.18.0 > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-13 20:42 ` Darrick J. Wong @ 2019-12-16 6:24 ` Yang Xu 2019-12-17 22:36 ` Darrick J. Wong 0 siblings, 1 reply; 9+ messages in thread From: Yang Xu @ 2019-12-16 6:24 UTC (permalink / raw) To: Darrick J. Wong; +Cc: fstests on 2019/12/14 4:42, Darrick J. Wong wrote: > On Fri, Dec 13, 2019 at 01:45:41PM +0800, Yang Xu wrote: >> When I test this case on xfs, it may fail as below: >> -------------------------------------------- >> === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === >> +umount: /mnt/xfstests/scratch: target is busy. >> + (In some cases useful info about processes that use >> + the device is found by lsof(8) or fuser(1)) >> --------------------------------------------- >> >> I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. >> >> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> >> --- >> tests/generic/520 | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tests/generic/520 b/tests/generic/520 >> index 167d7077..a16467ca 100755 >> --- a/tests/generic/520 >> +++ b/tests/generic/520 >> @@ -58,7 +58,7 @@ clean_dir() >> { >> _mount_flakey >> rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") >> - sync >> + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT > > But that only has to force the scratch mount directory to disk. > > Assuming the test authors really meant "write all of the scratch fs' > dirty data/metadata to disk", I think you want: > > $XFS_IO_PROG -c syncfs $SCRATCH_MNT > > here? My xfsprogs version doesn't support syncfs command. Or, we can use fsync to make four files(foo bar A/foo A/bar) write to disk? > > Also, why did umount spit out 'target is busy' here? clean_dir() erases > the scratch fs between tests, there shouldn't be anything flakey about > that. I try to find the cause of this but fail. I debug it but no useful output(using _unmount_flakey || fuser -uvm $SCRATCH_MNT ), failed as below: umount: /mnt/xfstests/scratch: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) USER PID ACCESS COMMAND /mnt/xfstests/scratch: root kernel mount (root)/mnt/xfstests/scratch ps: My test machine only excutes this cases and doesn't do other things. > > --D > >> _unmount_flakey >> } >> >> -- >> 2.18.0 >> >> >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-16 6:24 ` Yang Xu @ 2019-12-17 22:36 ` Darrick J. Wong 2019-12-18 2:37 ` Yang Xu 0 siblings, 1 reply; 9+ messages in thread From: Darrick J. Wong @ 2019-12-17 22:36 UTC (permalink / raw) To: Yang Xu; +Cc: fstests On Mon, Dec 16, 2019 at 02:24:56PM +0800, Yang Xu wrote: > > > on 2019/12/14 4:42, Darrick J. Wong wrote: > > On Fri, Dec 13, 2019 at 01:45:41PM +0800, Yang Xu wrote: > > > When I test this case on xfs, it may fail as below: > > > -------------------------------------------- > > > === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === > > > +umount: /mnt/xfstests/scratch: target is busy. > > > + (In some cases useful info about processes that use > > > + the device is found by lsof(8) or fuser(1)) > > > --------------------------------------------- > > > > > > I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. > > > > > > Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> > > > --- > > > tests/generic/520 | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/tests/generic/520 b/tests/generic/520 > > > index 167d7077..a16467ca 100755 > > > --- a/tests/generic/520 > > > +++ b/tests/generic/520 > > > @@ -58,7 +58,7 @@ clean_dir() > > > { > > > _mount_flakey > > > rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") > > > - sync > > > + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT > > > > But that only has to force the scratch mount directory to disk. > > > > Assuming the test authors really meant "write all of the scratch fs' > > dirty data/metadata to disk", I think you want: > > > > $XFS_IO_PROG -c syncfs $SCRATCH_MNT > > > > here? > My xfsprogs version doesn't support syncfs command. Or, we can use fsync to > make four files(foo bar A/foo A/bar) write to disk? Hmm, 'sync -f $SCRATCH_MNT' then? > > Also, why did umount spit out 'target is busy' here? clean_dir() erases > > the scratch fs between tests, there shouldn't be anything flakey about > > that. > I try to find the cause of this but fail. I debug it but no useful > output(using _unmount_flakey || fuser -uvm $SCRATCH_MNT ), failed as > below: > umount: /mnt/xfstests/scratch: target is busy. > (In some cases useful info about processes that use > the device is found by lsof(8) or fuser(1)) > USER PID ACCESS COMMAND > /mnt/xfstests/scratch: > root kernel mount (root)/mnt/xfstests/scratch > > ps: My test machine only excutes this cases and doesn't do other things. Does a second umount attempt succeed after the fuser fails to find anything sitting on the mount? --D > > > > --D > > > > > _unmount_flakey > > > } > > > -- > > > 2.18.0 > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-17 22:36 ` Darrick J. Wong @ 2019-12-18 2:37 ` Yang Xu 2019-12-19 17:08 ` Darrick J. Wong 0 siblings, 1 reply; 9+ messages in thread From: Yang Xu @ 2019-12-18 2:37 UTC (permalink / raw) To: Darrick J. Wong; +Cc: fstests on 2019/12/18 6:36, Darrick J. Wong wrote: > On Mon, Dec 16, 2019 at 02:24:56PM +0800, Yang Xu wrote: >> >> >> on 2019/12/14 4:42, Darrick J. Wong wrote: >>> On Fri, Dec 13, 2019 at 01:45:41PM +0800, Yang Xu wrote: >>>> When I test this case on xfs, it may fail as below: >>>> -------------------------------------------- >>>> === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === >>>> +umount: /mnt/xfstests/scratch: target is busy. >>>> + (In some cases useful info about processes that use >>>> + the device is found by lsof(8) or fuser(1)) >>>> --------------------------------------------- >>>> >>>> I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. >>>> >>>> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> >>>> --- >>>> tests/generic/520 | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/tests/generic/520 b/tests/generic/520 >>>> index 167d7077..a16467ca 100755 >>>> --- a/tests/generic/520 >>>> +++ b/tests/generic/520 >>>> @@ -58,7 +58,7 @@ clean_dir() >>>> { >>>> _mount_flakey >>>> rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") >>>> - sync >>>> + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT >>> >>> But that only has to force the scratch mount directory to disk. >>> >>> Assuming the test authors really meant "write all of the scratch fs' >>> dirty data/metadata to disk", I think you want: >>> >>> $XFS_IO_PROG -c syncfs $SCRATCH_MNT >>> >>> here? >> My xfsprogs version doesn't support syncfs command. Or, we can use fsync to >> make four files(foo bar A/foo A/bar) write to disk? > > Hmm, 'sync -f $SCRATCH_MNT' then? Both syncfs and sync -f are all useful when I test on 4.18.0-147.el8.x86_64. But on old system (3.10.0-1101.el7.x86_64 ), sync command doesn't support -f option. Or, I think we should use a generic way to avoid busy error. IMHO, it has two ways(mkfs and fsync), but mkfs will add more test time. What do you think about it? > >>> Also, why did umount spit out 'target is busy' here? clean_dir() erases >>> the scratch fs between tests, there shouldn't be anything flakey about >>> that. >> I try to find the cause of this but fail. I debug it but no useful >> output(using _unmount_flakey || fuser -uvm $SCRATCH_MNT ), failed as >> below: >> umount: /mnt/xfstests/scratch: target is busy. >> (In some cases useful info about processes that use >> the device is found by lsof(8) or fuser(1)) >> USER PID ACCESS COMMAND >> /mnt/xfstests/scratch: >> root kernel mount (root)/mnt/xfstests/scratch >> >> ps: My test machine only excutes this cases and doesn't do other things. > > Does a second umount attempt succeed after the fuser fails to find > anything sitting on the mount? Yes, second umount succeed. > > --D > >>> >>> --D >>> >>>> _unmount_flakey >>>> } >>>> -- >>>> 2.18.0 >>>> >>>> >>>> >>> >>> >> >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-18 2:37 ` Yang Xu @ 2019-12-19 17:08 ` Darrick J. Wong 2019-12-20 2:48 ` Yang Xu 0 siblings, 1 reply; 9+ messages in thread From: Darrick J. Wong @ 2019-12-19 17:08 UTC (permalink / raw) To: Yang Xu; +Cc: fstests On Wed, Dec 18, 2019 at 10:37:51AM +0800, Yang Xu wrote: > > > on 2019/12/18 6:36, Darrick J. Wong wrote: > > On Mon, Dec 16, 2019 at 02:24:56PM +0800, Yang Xu wrote: > > > > > > > > > on 2019/12/14 4:42, Darrick J. Wong wrote: > > > > On Fri, Dec 13, 2019 at 01:45:41PM +0800, Yang Xu wrote: > > > > > When I test this case on xfs, it may fail as below: > > > > > -------------------------------------------- > > > > > === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === > > > > > +umount: /mnt/xfstests/scratch: target is busy. > > > > > + (In some cases useful info about processes that use > > > > > + the device is found by lsof(8) or fuser(1)) > > > > > --------------------------------------------- > > > > > > > > > > I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. > > > > > > > > > > Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> > > > > > --- > > > > > tests/generic/520 | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/tests/generic/520 b/tests/generic/520 > > > > > index 167d7077..a16467ca 100755 > > > > > --- a/tests/generic/520 > > > > > +++ b/tests/generic/520 > > > > > @@ -58,7 +58,7 @@ clean_dir() > > > > > { > > > > > _mount_flakey > > > > > rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") > > > > > - sync > > > > > + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT > > > > > > > > But that only has to force the scratch mount directory to disk. > > > > > > > > Assuming the test authors really meant "write all of the scratch fs' > > > > dirty data/metadata to disk", I think you want: > > > > > > > > $XFS_IO_PROG -c syncfs $SCRATCH_MNT > > > > > > > > here? > > > My xfsprogs version doesn't support syncfs command. Or, we can use fsync to > > > make four files(foo bar A/foo A/bar) write to disk? > > > > Hmm, 'sync -f $SCRATCH_MNT' then? > Both syncfs and sync -f are all useful when I test on 4.18.0-147.el8.x86_64. > But on old system (3.10.0-1101.el7.x86_64 > ), sync command doesn't support -f option. Or, I think we should use a > generic way to avoid busy error. IMHO, it has two ways(mkfs and fsync), but > mkfs will add more test time. What do you think about it? Ahh, ok. I guess fsyncing the four things is fine then. > > > > Also, why did umount spit out 'target is busy' here? clean_dir() erases > > > > the scratch fs between tests, there shouldn't be anything flakey about > > > > that. > > > I try to find the cause of this but fail. I debug it but no useful > > > output(using _unmount_flakey || fuser -uvm $SCRATCH_MNT ), failed as > > > below: > > > umount: /mnt/xfstests/scratch: target is busy. > > > (In some cases useful info about processes that use > > > the device is found by lsof(8) or fuser(1)) > > > USER PID ACCESS COMMAND > > > /mnt/xfstests/scratch: > > > root kernel mount (root)/mnt/xfstests/scratch > > > > > > ps: My test machine only excutes this cases and doesn't do other things. > > > > Does a second umount attempt succeed after the fuser fails to find > > anything sitting on the mount? > Yes, second umount succeed. Also, which kernel behaves like this? Does it happen with upstream? AFAICT when running this in a loop on 5.5-rc2 it doesn't exhibit this failure, but maybe another kernel does? --D > > --D > > > > > > > > > > --D > > > > > > > > > _unmount_flakey > > > > > } > > > > > -- > > > > > 2.18.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-19 17:08 ` Darrick J. Wong @ 2019-12-20 2:48 ` Yang Xu 0 siblings, 0 replies; 9+ messages in thread From: Yang Xu @ 2019-12-20 2:48 UTC (permalink / raw) To: Darrick J. Wong; +Cc: fstests on 2019/12/20 1:08, Darrick J. Wong wrote: > On Wed, Dec 18, 2019 at 10:37:51AM +0800, Yang Xu wrote: >> >> >> on 2019/12/18 6:36, Darrick J. Wong wrote: >>> On Mon, Dec 16, 2019 at 02:24:56PM +0800, Yang Xu wrote: >>>> >>>> >>>> on 2019/12/14 4:42, Darrick J. Wong wrote: >>>>> On Fri, Dec 13, 2019 at 01:45:41PM +0800, Yang Xu wrote: >>>>>> When I test this case on xfs, it may fail as below: >>>>>> -------------------------------------------- >>>>>> === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === >>>>>> +umount: /mnt/xfstests/scratch: target is busy. >>>>>> + (In some cases useful info about processes that use >>>>>> + the device is found by lsof(8) or fuser(1)) >>>>>> --------------------------------------------- >>>>>> >>>>>> I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. >>>>>> >>>>>> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> >>>>>> --- >>>>>> tests/generic/520 | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/tests/generic/520 b/tests/generic/520 >>>>>> index 167d7077..a16467ca 100755 >>>>>> --- a/tests/generic/520 >>>>>> +++ b/tests/generic/520 >>>>>> @@ -58,7 +58,7 @@ clean_dir() >>>>>> { >>>>>> _mount_flakey >>>>>> rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") >>>>>> - sync >>>>>> + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT >>>>> >>>>> But that only has to force the scratch mount directory to disk. >>>>> >>>>> Assuming the test authors really meant "write all of the scratch fs' >>>>> dirty data/metadata to disk", I think you want: >>>>> >>>>> $XFS_IO_PROG -c syncfs $SCRATCH_MNT >>>>> >>>>> here? >>>> My xfsprogs version doesn't support syncfs command. Or, we can use fsync to >>>> make four files(foo bar A/foo A/bar) write to disk? >>> >>> Hmm, 'sync -f $SCRATCH_MNT' then? >> Both syncfs and sync -f are all useful when I test on 4.18.0-147.el8.x86_64. >> But on old system (3.10.0-1101.el7.x86_64 >> ), sync command doesn't support -f option. Or, I think we should use a >> generic way to avoid busy error. IMHO, it has two ways(mkfs and fsync), but >> mkfs will add more test time. What do you think about it? > > Ahh, ok. I guess fsyncing the four things is fine then.... > >>>>> Also, why did umount spit out 'target is busy' here? clean_dir() erases >>>>> the scratch fs between tests, there shouldn't be anything flakey about >>>>> that. >>>> I try to find the cause of this but fail. I debug it but no useful >>>> output(using _unmount_flakey || fuser -uvm $SCRATCH_MNT ), failed as >>>> below: >>>> umount: /mnt/xfstests/scratch: target is busy. >>>> (In some cases useful info about processes that use >>>> the device is found by lsof(8) or fuser(1)) >>>> USER PID ACCESS COMMAND >>>> /mnt/xfstests/scratch: >>>> root kernel mount (root)/mnt/xfstests/scratch >>>> >>>> ps: My test machine only excutes this cases and doesn't do other things. >>> >>> Does a second umount attempt succeed after the fuser fails to find >>> anything sitting on the mount? >> Yes, second umount succeed. > > Also, which kernel behaves like this? Does it happen with upstream? > AFAICT when running this in a loop on 5.5-rc2 it doesn't exhibit this > failure, but maybe another kernel does? 3.10.0-1101.el7.x86_64 and 4.18.0-147.el8.x86_64 all have the problem. Yes. I use upstream kernel 5.4+(commit head 76bb8b05960c3d16) on my vm(4G memory, 4Gswap, 20G test/scratch dev,2 cpu) and test it in a 100 loop. It fails 6 times . I think it fails because sync may make other things(such as system log or message) write to disk but maybe doesn't have enough time to make our rm options file to disk. ps: my colleague has a smiliar bug for generic/442 when we remove dm device. If you can review it, I will be very grateful. https://patchwork.kernel.org/patch/11160197/ > > --D > >>> --D >>> >>>>> >>>>> --D >>>>> >>>>>> _unmount_flakey >>>>>> } >>>>>> -- >>>>>> 2.18.0 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-13 5:45 [PATCH] generic/520: use fsync instead of sync during clean_dir Yang Xu 2019-12-13 20:42 ` Darrick J. Wong @ 2019-12-20 12:32 ` Filipe Manana 2019-12-23 5:01 ` Yang Xu 1 sibling, 1 reply; 9+ messages in thread From: Filipe Manana @ 2019-12-20 12:32 UTC (permalink / raw) To: Yang Xu; +Cc: fstests On Fri, Dec 13, 2019 at 5:45 AM Yang Xu <xuyang2018.jy@cn.fujitsu.com> wrote: > > When I test this case on xfs, it may fail as below: > -------------------------------------------- > === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === > +umount: /mnt/xfstests/scratch: target is busy. > + (In some cases useful info about processes that use > + the device is found by lsof(8) or fuser(1)) > --------------------------------------------- > > I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. It's indeed strange, and suggests something is still using the filesystem when trying to unmount it. I've never hit that problem (I usually only test btrfs), and a loop of 100 iterations running this test has never reproduced that issue (or any other) for me. Instead of fsync, I think you can simply do nothing (just remove the call to 'sync'), as the unmount is supposed to persist the file/directory removals. Does the problem reproduces this way? thanks > > Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> > --- > tests/generic/520 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/generic/520 b/tests/generic/520 > index 167d7077..a16467ca 100755 > --- a/tests/generic/520 > +++ b/tests/generic/520 > @@ -58,7 +58,7 @@ clean_dir() > { > _mount_flakey > rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") > - sync > + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT > _unmount_flakey > } > > -- > 2.18.0 > > > -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.” ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] generic/520: use fsync instead of sync during clean_dir 2019-12-20 12:32 ` Filipe Manana @ 2019-12-23 5:01 ` Yang Xu 0 siblings, 0 replies; 9+ messages in thread From: Yang Xu @ 2019-12-23 5:01 UTC (permalink / raw) To: fdmanana; +Cc: fstests on 2019/12/20 20:32, Filipe Manana wrote: > On Fri, Dec 13, 2019 at 5:45 AM Yang Xu <xuyang2018.jy@cn.fujitsu.com> wrote: >> >> When I test this case on xfs, it may fail as below: >> -------------------------------------------- >> === link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A === >> +umount: /mnt/xfstests/scratch: target is busy. >> + (In some cases useful info about processes that use >> + the device is found by lsof(8) or fuser(1)) >> --------------------------------------------- >> >> I think we don't need to sync all fs and fsync SCRATCH_MNT is enough. > > It's indeed strange, and suggests something is still using the > filesystem when trying to unmount it. > > I've never hit that problem (I usually only test btrfs), and a loop of > 100 iterations running this test has never reproduced that issue (or > any other) for me. > > Instead of fsync, I think you can simply do nothing (just remove the > call to 'sync'), as the unmount is supposed to persist the > file/directory removals. > Does the problem reproduces this way?Yes. I remove sync and test it with a loop of 100 iterations on xfs/ext4. It doesn't reproduce busy error. Thanks for your advise. I will remove sync in v2 patch. Kind Regards Yang Xu > > thanks > >> >> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> >> --- >> tests/generic/520 | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tests/generic/520 b/tests/generic/520 >> index 167d7077..a16467ca 100755 >> --- a/tests/generic/520 >> +++ b/tests/generic/520 >> @@ -58,7 +58,7 @@ clean_dir() >> { >> _mount_flakey >> rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found") >> - sync >> + $XFS_IO_PROG -c "fsync" $SCRATCH_MNT >> _unmount_flakey >> } >> >> -- >> 2.18.0 >> >> >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-12-23 5:01 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-13 5:45 [PATCH] generic/520: use fsync instead of sync during clean_dir Yang Xu 2019-12-13 20:42 ` Darrick J. Wong 2019-12-16 6:24 ` Yang Xu 2019-12-17 22:36 ` Darrick J. Wong 2019-12-18 2:37 ` Yang Xu 2019-12-19 17:08 ` Darrick J. Wong 2019-12-20 2:48 ` Yang Xu 2019-12-20 12:32 ` Filipe Manana 2019-12-23 5:01 ` Yang Xu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.