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