From: Hans van Kranenburg <Hans.van.Kranenburg@mendix.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 0/6] Chunk allocator DUP fix and cleanups
Date: Fri, 5 Oct 2018 10:58:19 +0000 [thread overview]
Message-ID: <a75d50c8-fb1a-8dc5-80c8-77acc7c4e4d0@mendix.com> (raw)
In-Reply-To: <10a9b7c4-861d-c6f6-b17b-56fa7a5ba5b8@gmx.com>
[-- Attachment #1.1: Type: text/plain, Size: 2513 bytes --]
On 10/05/2018 09:51 AM, Qu Wenruo wrote:
>
>
> On 2018/10/5 上午5:24, Hans van Kranenburg wrote:
>> This patch set contains an additional fix for a newly exposed bug after
>> the previous attempt to fix a chunk allocator bug for new DUP chunks:
>>
>> https://lore.kernel.org/linux-btrfs/782f6000-30c0-0085-abd2-74ec5827c903@mendix.com/T/#m609ccb5d32998e8ba5cfa9901c1ab56a38a6f374
>
> For that bug, did you succeeded in reproducing the bug?
Yes, open the above link and scroll to "Steps to reproduce".
o/
> I'm adding dev extent overlap checking in btrfs_verify_dev_extents() and
> btrfs-progs.
> I think it could help to detect such problem.
>
> Thanks,
> Qu
>
>>
>> The DUP fix is "fix more DUP stripe size handling". I did that one
>> before starting to change more things so it can be applied to earlier
>> LTS kernels.
>>
>> Besides that patch, which is fixing the bug in a way that is least
>> intrusive, I added a bunch of other patches to help getting the chunk
>> allocator code in a state that is a bit less error-prone and
>> bug-attracting.
>>
>> When running this and trying the reproduction scenario, I can now see
>> that the created DUP device extent is 827326464 bytes long, which is
>> good.
>>
>> I wrote and tested this on top of linus 4.19-rc5. I still need to create
>> a list of related use cases and test more things to at least walk
>> through a bunch of obvious use cases to see if there's nothing exploding
>> too quickly with these changes. However, I'm quite confident about it,
>> so I'm sharing all of it already.
>>
>> Any feedback and review is appreciated. Be gentle and keep in mind that
>> I'm still very much in a learning stage regarding kernel development.
>>
>> The stable patches handling workflow is not 100% clear to me yet. I
>> guess I have to add a Fixes: in the DUP patch which points to the
>> previous commit 92e222df7b.
>>
>> Moo!,
>> Knorrie
>>
>> Hans van Kranenburg (6):
>> btrfs: alloc_chunk: do not refurbish num_bytes
>> btrfs: alloc_chunk: improve chunk size variable name
>> btrfs: alloc_chunk: fix more DUP stripe size handling
>> btrfs: fix ncopies raid_attr for RAID56
>> btrfs: introduce nparity raid_attr
>> btrfs: alloc_chunk: rework chunk/stripe calculations
>>
>> fs/btrfs/volumes.c | 84 +++++++++++++++++++++++-----------------------
>> fs/btrfs/volumes.h | 4 ++-
>> 2 files changed, 45 insertions(+), 43 deletions(-)
>>
>
--
Hans van Kranenburg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-10-05 10:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 21:24 [PATCH 0/6] Chunk allocator DUP fix and cleanups Hans van Kranenburg
2018-10-04 21:24 ` [PATCH 1/6] btrfs: alloc_chunk: do not refurbish num_bytes Hans van Kranenburg
2018-10-05 8:59 ` Nikolay Borisov
2018-10-05 9:00 ` Nikolay Borisov
2018-10-04 21:24 ` [PATCH 2/6] btrfs: alloc_chunk: improve chunk size variable name Hans van Kranenburg
2018-10-04 21:36 ` Hans van Kranenburg
2018-10-05 9:00 ` Nikolay Borisov
2018-10-04 21:24 ` [PATCH 3/6] btrfs: alloc_chunk: fix more DUP stripe size handling Hans van Kranenburg
2018-10-04 21:24 ` [PATCH 4/6] btrfs: fix ncopies raid_attr for RAID56 Hans van Kranenburg
2018-10-05 9:10 ` Nikolay Borisov
2018-10-04 21:24 ` [PATCH 5/6] btrfs: introduce nparity raid_attr Hans van Kranenburg
2018-10-04 22:21 ` Hans van Kranenburg
2018-10-05 14:42 ` Nikolay Borisov
2018-10-05 22:45 ` Hans van Kranenburg
2018-10-04 21:24 ` [PATCH 6/6] btrfs: alloc_chunk: rework chunk/stripe calculations Hans van Kranenburg
2018-10-05 7:51 ` [PATCH 0/6] Chunk allocator DUP fix and cleanups Qu Wenruo
2018-10-05 10:58 ` Hans van Kranenburg [this message]
2018-10-08 6:43 ` Qu Wenruo
2018-10-08 13:19 ` Hans van Kranenburg
2018-10-08 23:51 ` Hans van Kranenburg
2018-10-05 7:51 ` Qu Wenruo
2018-10-11 15:13 ` David Sterba
2018-10-11 19:40 ` Hans van Kranenburg
2018-10-11 20:34 ` Hans van Kranenburg
2018-11-13 15:03 ` David Sterba
2018-11-13 16:45 ` Hans van Kranenburg
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=a75d50c8-fb1a-8dc5-80c8-77acc7c4e4d0@mendix.com \
--to=hans.van.kranenburg@mendix.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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;
as well as URLs for NNTP newsgroup(s).