on 2019/12/20 20:32, Filipe Manana wrote:
On Fri, Dec 13, 2019 at 5:45 AM Yang Xu <xuyang2018.jy@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
---
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
