on 2019/12/20 1:08, Darrick J. Wong wrote:
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?
3.10.0-1101.el7.x86_64 and 4.18.0-147.el8.x86_64 all have the problem.
Yes. I use upstream kernel 5.4+(commit head 76bb8b05960c3d16) on my
vm(4G memory, 4Gswap, 20G test/scratch dev,2 cpu) and test it in a 100
loop. It fails 6 times . I think it fails because sync may make other
things(such as system log or message) write to disk but maybe doesn't
have enough time to make our rm options file to disk.
ps: 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/
--D
--D
--D
_unmount_flakey
}
--
2.18.0
