Re: xfstests: generic/342 run failed in f2fs

Chen Rong
2017-12-25T06:30:51Z

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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>