FSTests Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v2] generic/520: Remove sync in clean_dir
@ 2019-12-23 10:21 Yang Xu
  2020-01-16  9:28 ` Yang Xu
  2020-01-16 15:35 ` Darrick J. Wong
  0 siblings, 2 replies; 4+ messages in thread
From: Yang Xu @ 2019-12-23 10:21 UTC (permalink / raw)
  To: fdmanana; +Cc: darrick.wong, fstests, 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))
---------------------------------------------

It fails because somethings is still using the fs when we call sync and then
try to unmount it. We can simply remove sync as the unmount is supposed to
persist the file/directory removals.

Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
---
 tests/generic/520 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tests/generic/520 b/tests/generic/520
index 167d7077..d4457370 100755
--- a/tests/generic/520
+++ b/tests/generic/520
@@ -58,7 +58,6 @@ clean_dir()
 {
 	_mount_flakey
 	rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found")
-	sync
 	_unmount_flakey
 }
 
-- 
2.18.0




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] generic/520: Remove sync in clean_dir
  2019-12-23 10:21 [PATCH v2] generic/520: Remove sync in clean_dir Yang Xu
@ 2020-01-16  9:28 ` Yang Xu
  2020-01-16 15:35 ` Darrick J. Wong
  1 sibling, 0 replies; 4+ messages in thread
From: Yang Xu @ 2020-01-16  9:28 UTC (permalink / raw)
  To: fdmanana; +Cc: darrick.wong, fstests


on 2019/12/23 18:21, 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))
> ---------------------------------------------
Does someone review this?
> 
> It fails because somethings is still using the fs when we call sync and then
> try to unmount it. We can simply remove sync as the unmount is supposed to
> persist the file/directory removals.
> 
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> ---
>   tests/generic/520 | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/tests/generic/520 b/tests/generic/520
> index 167d7077..d4457370 100755
> --- a/tests/generic/520
> +++ b/tests/generic/520
> @@ -58,7 +58,6 @@ clean_dir()
>   {
>   	_mount_flakey
>   	rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found")
> -	sync
>   	_unmount_flakey
>   }
>   
> 



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] generic/520: Remove sync in clean_dir
  2019-12-23 10:21 [PATCH v2] generic/520: Remove sync in clean_dir Yang Xu
  2020-01-16  9:28 ` Yang Xu
@ 2020-01-16 15:35 ` Darrick J. Wong
  2020-01-17  2:57   ` Yang Xu
  1 sibling, 1 reply; 4+ messages in thread
From: Darrick J. Wong @ 2020-01-16 15:35 UTC (permalink / raw)
  To: Yang Xu; +Cc: fdmanana, fstests

On Mon, Dec 23, 2019 at 06:21:39PM +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))
> ---------------------------------------------
> 
> It fails because somethings is still using the fs when we call sync and then
> try to unmount it. We can simply remove sync as the unmount is supposed to
> persist the file/directory removals.

/me continues to wonder why the target is busy in this case, but as the
sync truly isn't necessary:

Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>

--D

> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> ---
>  tests/generic/520 | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/tests/generic/520 b/tests/generic/520
> index 167d7077..d4457370 100755
> --- a/tests/generic/520
> +++ b/tests/generic/520
> @@ -58,7 +58,6 @@ clean_dir()
>  {
>  	_mount_flakey
>  	rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found")
> -	sync
>  	_unmount_flakey
>  }
>  
> -- 
> 2.18.0
> 
> 
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] generic/520: Remove sync in clean_dir
  2020-01-16 15:35 ` Darrick J. Wong
@ 2020-01-17  2:57   ` Yang Xu
  0 siblings, 0 replies; 4+ messages in thread
From: Yang Xu @ 2020-01-17  2:57 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: fdmanana, fstests

on 2020/01/16 23:35, Darrick J. Wong wrote:
> On Mon, Dec 23, 2019 at 06:21:39PM +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))
>> ---------------------------------------------
>>
>> It fails because somethings is still using the fs when we call sync and then
>> try to unmount it. We can simply remove sync as the unmount is supposed to
>> persist the file/directory removals.
> 
> /me continues to wonder why the target is busy in this case, but as the
> sync truly isn't necessary:
I don't konw(I use fuser or lsof to debug, but no useful info).  I guess 
call sync frequently in a case will cause this. sync doesn't ensure 
cached push into disk, also sync doesn't have fixed order(it may push 
other into disk, then push SCRATCH_DEV cached write into disk, between 
them, umount will report target busy, this happens randomly).

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

Best Regard
Yang Xu
> 
> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
> 
> --D
> 
>> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
>> ---
>>   tests/generic/520 | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/tests/generic/520 b/tests/generic/520
>> index 167d7077..d4457370 100755
>> --- a/tests/generic/520
>> +++ b/tests/generic/520
>> @@ -58,7 +58,6 @@ clean_dir()
>>   {
>>   	_mount_flakey
>>   	rm -rf $(find $SCRATCH_MNT/* | grep -v "lost+found")
>> -	sync
>>   	_unmount_flakey
>>   }
>>   
>> -- 
>> 2.18.0
>>
>>
>>
> 
> 



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-23 10:21 [PATCH v2] generic/520: Remove sync in clean_dir Yang Xu
2020-01-16  9:28 ` Yang Xu
2020-01-16 15:35 ` Darrick J. Wong
2020-01-17  2:57   ` Yang Xu

FSTests Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/fstests/0 fstests/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 fstests fstests/ https://lore.kernel.org/fstests \
		fstests@vger.kernel.org
	public-inbox-index fstests

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.fstests


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git