linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jayashree Mohan <jayashree2912@gmail.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Filipe Manana <fdmanana@kernel.org>,
	fstests <fstests@vger.kernel.org>,
	Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] generic: add test for fsync after shrinking truncate and rename
Date: Thu, 7 Mar 2019 17:19:51 -0600	[thread overview]
Message-ID: <CA+EzBbCuQJen9hSHf8-JSRGG3VPxo9X4ugscMdKuw_A6isHDUQ@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxjM0-D8c3KR0ooXYhhUa5+19j_=3XUaXf6vGMbsNhShJw@mail.gmail.com>

Hi Amir,

> I went back to look at similar fsync tests by Filipe:
> generic/{106,107,335,336,341,342,343,348,498,501,502,509,510,512}
>
> I found some alleged subtle mistakes about SOMC assumptions.
>
> generic/336 does:
> touch $SCRATCH_MNT/a/foo
> ln $SCRATCH_MNT/a/foo $SCRATCH_MNT/b/foo_link
> touch $SCRATCH_MNT/b/bar
> sync
> unlink $SCRATCH_MNT/b/foo_link
> mv $SCRATCH_MNT/b/bar $SCRATCH_MNT/c/
> $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/a/foo

This is probably what's happening in this particular test :

SOMC requires:
          fsync(a/foo) must ensure unlink(b/foo_link)  (because they
were linked at some point)

But what happens is:
           fsync(a/foo)          -->  unlink(b/foo_link)
           unlink(b/foo_link)  -->  fsync(b)
           fsync(b)                 -->  rename goes through

SOMC should only require that the unlink persists. The rename
operation persists due to the side-effect of SOMC. So we should be
only testing if the unlink operation went through.

Take a look at this thread that describes the bug which resulted in
this test case (https://patchwork.kernel.org/patch/8293181/).
The file bar was lost during the rename operation and I think this
test simply wanted to verify that file bar was intact in either one of
the directories. Probably the reason this test was written was not to
test SOMC, but to verify that the log replay in btrfs does not delete
the renamed file - luckily it happens to pass on other file systems
because they all persist the rename operation as a side effect of
SOMC. To me, this test currently checks for something more than SOMC.
The check must be modified to only test if b/foo_link is removed, and
that the file bar is *either* in directory b or c.

Test 343 is a similar case where in btrfs log replay ended up
persisting the file in both the source and destination directories
after a rename operation
(https://patchwork.kernel.org/patch/8766401/). The checks must be
updated here as well.

Thanks,
Jayashree

  reply	other threads:[~2019-03-07 23:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-04 14:06 [PATCH] generic: add test for fsync after shrinking truncate and rename fdmanana
2019-03-04 15:04 ` Amir Goldstein
2019-03-04 15:23   ` Filipe Manana
2019-03-04 17:59     ` Amir Goldstein
2019-03-04 22:30       ` Filipe Manana
2019-03-05  5:59         ` Amir Goldstein
2019-03-05  9:26           ` Filipe Manana
2019-03-05 10:51             ` Amir Goldstein
2019-03-05  0:50   ` Dave Chinner
2019-03-05  1:00     ` Dave Chinner
2019-03-05  1:08       ` Vijay Chidambaram
2019-03-05  5:39     ` Amir Goldstein
2019-03-05 22:33       ` Dave Chinner
2019-03-06  7:51         ` Amir Goldstein
2019-03-06 21:48           ` Dave Chinner
2019-03-07  7:52             ` Amir Goldstein
2019-03-07 23:19               ` Jayashree Mohan [this message]
2019-03-08  4:35                 ` Dave Chinner
2019-03-08 15:11                   ` Vijay Chidambaram
2019-03-19  1:13                     ` Dave Chinner
2019-03-08  3:46               ` Dave Chinner
2019-03-05  9:26 ` [PATCH v2] " fdmanana

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=CA+EzBbCuQJen9hSHf8-JSRGG3VPxo9X4ugscMdKuw_A6isHDUQ@mail.gmail.com \
    --to=jayashree2912@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=david@fromorbit.com \
    --cc=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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).