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?
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
>
>
>
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
