(Add to Cc: Ben Hutchings)
On 1/23/19 7:18 PM, Sasha Levin wrote:
> 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@xxxxxxxxxx>
>>>>>
>>>>> [ 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.
Ok, I get it.
The changes are really limited to the few lines in that if block. And
793ff2c88c6 also is, and it doesn't change the behavior, so that's good.
For 3.16.y it also first needs a little part of b8b93addde from David
Sterba, which is a collection of coding style changes in quite some
places. After that 793ff2c88c6 and then baf92114c7 apply cleanly, only
touch that single part of the code and end up with the right thing.
I attached 3.16.y-WIP-partially-apply-b8b93addde.patch as quick and
dirty example, please let me know how this should be done properly.
For 4.4, 4.9 and 4.14, first 793ff2c88c6 and then baf92114c7 indeed also
end up with the right thing. I just tried that here.
Thanks,
--
Hans van Kranenburg
From f56c231f4251fd2cae5e5ab3ccc39e57c57c83ca Mon Sep 17 00:00:00 2001
From: Hans van Kranenburg <hans@xxxxxxxxxxx>
Date: Wed, 23 Jan 2019 20:03:49 +0100
Subject: [PATCH] WIP partially apply b8b93addde
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 4aa1a20fc5d7..b4b98a75ca8b 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4274,8 +4274,8 @@ static int __btrfs_alloc_chunk(struct btrfs_trans_handle *trans,
*/
if (stripe_size * data_stripes > max_chunk_size) {
u64 mask = (1ULL << 24) - 1;
- stripe_size = max_chunk_size;
- do_div(stripe_size, data_stripes);
+
+ stripe_size = div_u64(max_chunk_size, data_stripes);
/* bump the answer up to a 16MB boundary */
stripe_size = (stripe_size + mask) & ~mask;
--
2.20.1
