From: Sasha Levin <sashal@kernel.org>
To: Hans van Kranenburg <Hans.van.Kranenburg@mendix.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
David Sterba <dsterba@suse.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH AUTOSEL 4.20 072/117] btrfs: alloc_chunk: fix more DUP stripe size handling
Date: Wed, 23 Jan 2019 13:18:05 -0500 [thread overview]
Message-ID: <20190123181805.GM202535@sasha-vm> (raw)
In-Reply-To: <cb62ab8d-7d6f-de02-2912-3d9391a2bbb2@mendix.com>
On Wed, Jan 23, 2019 at 03:54:00PM +0000, Hans van Kranenburg wrote:
>On 1/23/19 3:37 PM, Sasha Levin wrote:
>> On Tue, Jan 08, 2019 at 11:52:02PM +0000, Hans van Kranenburg wrote:
>>> Hi Sasha,
>>>
>>> On 1/8/19 8:25 PM, Sasha Levin wrote:
>>>> From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
>>>>
>>>> [ Upstream commit baf92114c7e6dd6124aa3d506e4bc4b694da3bc3 ]
>>>>
>>>> Commit 92e222df7b "btrfs: alloc_chunk: fix DUP stripe size handling"
>>>> fixed calculating the stripe_size for a new DUP chunk.
>>>
>>> That one also ended up as:
>>>
>>> 4.14-stable
>>> 0136bd7238b2cb8238426af4183ed0b02165c3f9
>>>
>>> 4.9-stable
>>> 8890bae03f4dba1c2292e5445682b556af4e8f1b
>>>
>>> 4.4-stable
>>> 97c3e46ef53748278286fc09dcc30b138d6677c4
>>>
>>> 3.16.57-rc1
>>> f68f46284a199f6837c1d5b94a6ae979a2cc463c
>>>
>>> While hitting the failure condition without adding "crafting" steps to
>>> make it exactly match the scenario is unlikely, it might be good if we
>>> just go all the way back with this regression fix?
>>
>> What do you mean with "all the way back"?
>
>Oh, apologies for not using unambigious phrasing.
>
>I mean, it seems the autoselection only found 92e222df7b in places where
>it's actually called 92e222df7b, and not where it was cherry-picked.
>
>So, for my own understanding: If I have to do something like this ever
>again, then should I have added it like this inside baf92114c?
>
>Fixes: 92e222df7b ("btrfs: alloc_chunk: fix DUP stripe size handling")
>Fixes: 0136bd7238 ("btrfs: alloc_chunk: fix DUP stripe size handling")
>Fixes: 8890bae03f ("btrfs: alloc_chunk: fix DUP stripe size handling")
>Fixes: 97c3e46ef5 ("btrfs: alloc_chunk: fix DUP stripe size handling")
>Fixes: f68f46284a ("btrfs: alloc_chunk: fix DUP stripe size handling")
>
>Thanks for your patience, :)
Ah, the scripts have enough "brains" to deal with these on their own, so
no need to annotate that much.
This patch wasn't applied to older trees because it didn't cherry-pick
cleanly on top of them. Looking at it now, it seems to depend on
793ff2c88c6 ("btrfs: volumes: Cleanup stripe size calculation") which
can possibly be picked up if it makes sense.
--
Thanks,
Sasha
next prev parent reply other threads:[~2019-01-23 18:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190108192628.121270-1-sashal@kernel.org>
2019-01-08 19:25 ` [PATCH AUTOSEL 4.20 071/117] btrfs: volumes: Make sure there is no overlap of dev extents at mount time Sasha Levin
2019-01-08 19:25 ` [PATCH AUTOSEL 4.20 072/117] btrfs: alloc_chunk: fix more DUP stripe size handling Sasha Levin
2019-01-08 23:52 ` Hans van Kranenburg
2019-01-23 14:37 ` Sasha Levin
2019-01-23 15:54 ` Hans van Kranenburg
2019-01-23 17:41 ` David Sterba
2019-01-23 18:18 ` Sasha Levin [this message]
2019-01-23 19:32 ` Hans van Kranenburg
2019-11-19 15:23 ` Ben Hutchings
2019-01-08 19:25 ` [PATCH AUTOSEL 4.20 073/117] btrfs: fix use-after-free due to race between replace start and cancel Sasha Levin
2019-01-08 19:25 ` [PATCH AUTOSEL 4.20 074/117] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation Sasha Levin
2019-01-08 19:25 ` [PATCH AUTOSEL 4.20 075/117] Btrfs: fix access to available allocation bits when starting balance Sasha Levin
2019-01-08 19:25 ` [PATCH AUTOSEL 4.20 076/117] btrfs: improve error handling of btrfs_add_link Sasha Levin
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=20190123181805.GM202535@sasha-vm \
--to=sashal@kernel.org \
--cc=Hans.van.Kranenburg@mendix.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@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).