Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: fstests <fstests@vger.kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] generic/527: add additional test including a file with a hardlink
Date: Thu, 16 Jan 2020 16:16:45 +0000
Message-ID: <CAL3q7H655byvBYD8-wvHwDWJaWZumvyyj3bvYTOjuVZtFLjJ-w@mail.gmail.com> (raw)
In-Reply-To: <785ebd3c-89cb-0079-782c-9fd1e07116fa@toxicpanda.com>

On Thu, Jan 16, 2020 at 4:05 PM Josef Bacik <josef@toxicpanda.com> wrote:
>
> On 1/15/20 8:22 AM, fdmanana@kernel.org wrote:
> > From: Filipe Manana <fdmanana@suse.com>
> >
> > Add a similar test to the existing one but with a file that has a
> > hardlink as well. This is motivated by a bug found in btrfs where
> > a fsync on a file that has the old name of another file results
> > in the logging code to hit an infinite loop. The patch that fixes
> > the bug in btrfs has the following subject:
> >
> >    "Btrfs: fix infinite loop during fsync after rename operations"
> >
> > Signed-off-by: Filipe Manana <fdmanana@suse.com>
>
> What's our policy on adding a new variant to an existing test?  I thought we
> preferred to create a new test for these sort of things?  If not then you can add

Usually yes, but since over time there started to be too many fsync
related tests, we had a discussion with Dave (Chinner)
and others about considering consolidating more tests into the same
files. It's not just the number of test files, but more time to run
(even if each one adds only 1 or 2 seconds).

That's why I opted here to update generic/527 instead of adding a new test file.
Thanks.

>
> Reviewed-by: Josef Bacik <josef@toxicpanda.com>
>
> I have no strong opinions either way, I just know it's come up in the past.  Thanks,
>
> Josef

      reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 13:22 fdmanana
2020-01-16 16:05 ` Josef Bacik
2020-01-16 16:16   ` Filipe Manana [this message]

Reply instructions:

You may reply publically 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=CAL3q7H655byvBYD8-wvHwDWJaWZumvyyj3bvYTOjuVZtFLjJ-w@mail.gmail.com \
    --to=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=josef@toxicpanda.com \
    --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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org
	public-inbox-index linux-btrfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git