Re: xfstests: generic/342 run failed in f2fs

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]





On 2017年12月25日 13:56, Eric Sandeen wrote:
On 12/24/17 9:28 PM, Chen Rong wrote:
Hi, everyone:

the issue as below:
First we need to look - what does the test do?

# Test that if we rename a file, create a new file that has the old name of the
# other file and is a child of the same parent directory, fsync the new inode,
# power fail and mount the filesystem, we do not lose the first file and that
# file has the name it was renamed to.

Ok, so it is a test of fsync'd file renames/creation over simulated device
failure, and wants to be sure that all files and file contents are as
expected if data integrity syscalls were made before the device failure.

# ./check generic/342
FSTYP         -- f2fs
PLATFORM      -- Linux/x86_64 node01 4.15.0-rc4
MKFS_OPTIONS  -- /dev/sde1
MOUNT_OPTIONS -- -o acl,user_xattr /dev/sde1 /tmp/test1

generic/342      - output mismatch (see /home/ubuntu/git/xfstests-dev/results//generic/342.out.bad)
     --- tests/generic/342.out   2017-12-13 13:47:20.144000000 -0500
     +++ /home/ubuntu/git/xfstests-dev/results//generic/342.out.bad 2017-12-25 11:13:12.928000000 -0500
     @@ -8,8 +8,7 @@
      48c940ba3b8671d3d6ea74e4ccad8ca3  SCRATCH_MNT/a/bar
      Directory a/ contents after log replay:
      SCRATCH_MNT/a:
     -bar
the test created foo, fsynced it, then renamed it to bar and created a
/new/ file also named foo, then fsynced the new file foo.

Despite that 2nd fsync, the renamed file "bar" is not present in
your case.

However, don't we really need to fsync the directory after
the rename and recreation to ensure persistence?

iows:  does this patch make the test pass on f2fs?  It does
for me, and I think it's the only valid way to run the test:
the patch works for me. but btrfs could pass the test without it, why so different?
diff --git a/tests/generic/342 b/tests/generic/342
index ed64e05..6a9e5bd 100755
--- a/tests/generic/342
+++ b/tests/generic/342
@@ -68,6 +68,7 @@ sync
  mv $SCRATCH_MNT/a/foo $SCRATCH_MNT/a/bar
  $XFS_IO_PROG -f -c "pwrite -S 0xba 0 16K" $SCRATCH_MNT/a/foo | _filter_xfs_io
  $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/a/foo
+$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/a
echo "File digests before log replay:"
  md5sum $SCRATCH_MNT/a/foo | _filter_scratch

without an fsync of the parent dir, I don't think we can
guarantee that filename changes or additions will persist
on every filesystem.

      foo
      File digests after log replay:
      9e5d56a1f9b2c93589f9d55480f971a1  SCRATCH_MNT/a/foo
     ...
     (Run 'diff -u tests/generic/342.out /home/ubuntu/git/xfstests-dev/results//generic/342.out.bad'  to see the entire diff)
Generally best to do that suggested diff command to see if
there are any more pieces of changed/wrong test output.

Ran: generic/342
Failures: generic/342
Failed 1 of 1 tests

Is it a problem with my computer or a already known issue with f2fs?
or a problem with the test itself ...
cool!

-Eric
thanks!

--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux