Re: [PATCH] generic/520: use fsync instead of sync during clean_dir

["Darrick J. Wong" <darrick.wong@oracle.com>]

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@cn.fujitsu.com>
> > > ---
> > >   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?

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

--D

> > 
> > --D
> > 
> > >   	_unmount_flakey
> > >   }
> > > -- 
> > > 2.18.0
> > > 
> > > 
> > > 
> > 
> > 
> 
>