| Message ID | 1577096499-23471-1-git-send-email-xuyang2018.jy@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] generic/520: Remove sync in clean_dir | expand |
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 > } > >
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 > > >
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 >> >> >> > >
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 }
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(-)