[PATCH] generic/520: use fsync instead of sync during clean_dir

[PATCH] generic/520: use fsync instead of sync during clean_dir

[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

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Darrick J. Wong]

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

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Yang Xu]

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

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Darrick J. Wong]

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

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Yang Xu]

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

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Darrick J. Wong]

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

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Yang Xu]

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

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Filipe Manana]

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.”

Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

[Yang Xu]

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