Re: [PATCH v2] Btrfs: fix race between send and deduplication that lead to failures and crashes

From: David Sterba <dsterba@suse.cz>
To: David Sterba <dsterba@suse.cz>
Cc: Filipe Manana <fdmanana@kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2] Btrfs: fix race between send and deduplication that lead to failures and crashes
Date: Tue, 14 May 2019 00:06:26 +0200	[thread overview]
Message-ID: <20190513220626.GL3138@twin.jikos.cz> (raw)
In-Reply-To: <20190513191003.GK3138@twin.jikos.cz>

On Mon, May 13, 2019 at 09:10:03PM +0200, David Sterba wrote:
> On Mon, May 13, 2019 at 06:05:54PM +0100, Filipe Manana wrote:
> > On Mon, May 13, 2019 at 5:57 PM David Sterba <dsterba@suse.cz> wrote:
> > >
> > > On Mon, May 13, 2019 at 05:18:37PM +0100, Filipe Manana wrote:
> > > > I would leave it as it is unless users start to complain. Yes, the
> > > > test does this on purpose.
> > > > Adding such code/state seems weird to me, instead I would change the
> > > > rate limit state so that the messages would repeat much less
> > > > frequently.
> > >
> > > The difference to the state tracking is that the warning would be
> > > printed repeatedly, which I find unnecessary and based on past user
> > > feedback, there will be somebody asking about that.
> > >
> > > The rate limiting can also skip a message that can be for a different
> > > subvolume, so this makes it harder to diagnose problems.
> > >
> > > Current state is not satisfactory at least for me because it hurts
> > > testing, the test runs for about 2 hours now, besides the log bloat. The
> > 
> > You mean the test case for fstests (btrfs/187) takes 2 hours for you?
> 
> This is on a VM with file-backed devices, that I use for initial tests
> of patches before they go to other branches.

Update: it took about 6 minutes in another round, so the test does work
in that setup.