From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: fdmanana@gmail.com, dsterba@suse.cz, Qu Wenruo <wqu@suse.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] btrfs: scrub: Require mandatory block group RO for dev-replace
Date: Sat, 25 Jan 2020 12:35:31 +0100 [thread overview]
Message-ID: <20200125113531.GR3929@twin.jikos.cz> (raw)
In-Reply-To: <a76b187d-678e-1b02-b388-2ab12b9c221c@gmx.com>
On Sat, Jan 25, 2020 at 08:36:14AM +0800, Qu Wenruo wrote:
> >> The purpose seems to be to catch generic error codes other than
> >> EINPROGRESS and ECNACELED, I don't see much point printing a warning in
> >> that case. But it' a new ENOSPC problem, likely caused by the
> >> read-only status switching.
> >>
> >> My test devices are 12G, there's full log of the test to see at which
> >> phase it happened.
> >
> > It passes for me on 20G devices, haven't tested with 12G however
> > (can't afford to reboot any of my vms now).
>
> 5G for all scratch devices, and failed to reproduce it.
> (The full run before submitting the patch also failed to reproduce it)
5G is not actually enough to run some of the tests that require at least
10G of free space (so the block device needs to be a bit larger).
> > I think that happens because before this patch we ignored ENOSPC
> > errors, when trying to set a block group to RO, for device replace and
> > scrub.
> > But with this patch we don't ignore ENOSPC for device replace anymore
> > - this is actually correct because if we ignore we can corrupt nocow
> > writes (including writes into prealloc extents).
> >
> > Now if it's a real ENOSPC situation or just a bug in the space
> > management code, it's a different thing to look at.
>
> I tend to take a middle land of the problem.
>
> For current stage, the WARN_ON() is indeed overkilled, at least for ENOSPC.
>
> But on the other handle, the full RO of a block group for scrub/replace
> is also a little overkilled.
> Just as Filipe mentioned, we only want to kill nocow writes into a block
> group, but still allow COW writes.
>
> It looks like something like mark_block_group_nocow_ro() in the future
> could reduce the possibility if not fully kill it.
Yeah this sounds doable.
> It looks like changing the WARN_ON(ret) to WARN_ON(ret != -ENOSPC) would
> be needed for this patch as a quick fix.
I'll remove the warning completely, as a separate patch.
next prev parent reply other threads:[~2020-01-25 11:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 23:58 [PATCH] btrfs: scrub: Require mandatory block group RO for dev-replace Qu Wenruo
2020-01-24 9:24 ` Filipe Manana
2020-01-24 13:40 ` David Sterba
2020-01-24 14:44 ` David Sterba
2020-01-24 16:28 ` Filipe Manana
2020-01-25 0:36 ` Qu Wenruo
2020-01-25 0:48 ` Qu Wenruo
2020-01-25 11:35 ` David Sterba [this message]
2020-01-25 12:09 ` Qu WenRuo
-- strict thread matches above, loose matches on Subject: below --
2020-01-23 7:37 Qu Wenruo
2020-01-23 12:06 ` Filipe Manana
2020-01-23 12:28 ` Qu WenRuo
2020-01-23 13:39 ` Qu Wenruo
2020-01-23 13:49 ` Filipe Manana
2020-01-23 13:57 ` Qu Wenruo
2020-01-23 16:40 ` David Sterba
2020-01-23 23:58 ` Qu Wenruo
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=20200125113531.GR3929@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=fdmanana@gmail.com \
--cc=fdmanana@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/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