linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Chen Rong <rongx.a.chen@intel.com>
To: Eric Sandeen <sandeen@sandeen.net>,
	fstests@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Cc: philip.li@intel.com
Subject: Re: xfstests: generic/342 run failed in f2fs
Date: Mon, 25 Dec 2017 14:30:13 +0800	[thread overview]
Message-ID: <d20cb58e-6646-a7de-bff1-8b7783a30664@intel.com> (raw)
In-Reply-To: <e367054d-046d-d6e5-943c-7fbe10493029@sandeen.net>



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

  reply	other threads:[~2017-12-25  6:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-25  5:28 xfstests: generic/342 run failed in f2fs Chen Rong
2017-12-25  5:56 ` Eric Sandeen
2017-12-25  6:30   ` Chen Rong [this message]
2017-12-25  7:47     ` Eric Sandeen
2017-12-25 16:31       ` Theodore Ts'o
2017-12-27 19:11         ` Jaegeuk Kim
2017-12-28  3:17           ` Chao Yu
2017-12-28  3:41             ` Theodore Ts'o
2017-12-28  9:09           ` Dave Chinner
2017-12-28 16:29             ` Jaegeuk Kim
2017-12-28 16:59             ` Eric Sandeen
2017-12-28 21:21               ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d20cb58e-6646-a7de-bff1-8b7783a30664@intel.com \
    --to=rongx.a.chen@intel.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=philip.li@intel.com \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).