public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: "Yu Kuai" <yukuai@fnnas.com>
To: "Su Yue" <glass.su@suse.com>, <linux-raid@vger.kernel.org>
Cc: <song@kernel.org>, <xni@redhat.com>,
	 "linan122@huawei.com >> Li Nan" <linan122@huawei.com>,
	 <yukuai@fnnas.com>, "Heming Zhao" <heming.zhao@suse.com>
Subject: Re: [PATCH v2 0/5] md: bitmap grow fixes
Date: Tue, 21 Apr 2026 13:15:04 +0800	[thread overview]
Message-ID: <afb84561-e7c4-4d08-b7ca-bd20e9f8dbda@fnnas.com> (raw)
In-Reply-To: <20260407102625.5686-1-glass.su@suse.com>

Hi,

在 2026/4/7 18:26, Su Yue 写道:
> Hi, This v2 series is to fixes bugs exposed by mdadm/clustermd-autotest.
> The bugs are not cluster md only but also bitmap related.
>
> The series based on v7.0-rc7 passes tests with mdadm v4.6 without regression.
>
> v2:
>      Add a dummy bitmap operations per Kuai's suggestion.
>
> To Yu Kuai:
> A NULL group can't used for internal_bitmap_group since
> the entries from internal_bitmap_attrs should be under bitmap.
> So instead of sysfs_create_groups(), sysfs_create_group() and sysfs_merge_group()
> are still needed /sigh.

Thanks for the set and sorry for the delay.

TBO, this set is still a bit complex than expected. It's true sysfs_create_groups()
can't be used for the groups with same name. However, there is still another api
sysfs_update_groups() that can be used in this case.

I just finish a local version and confirm following 3 commits should be enough:

1) factor out bitmap sysfs creation from mddev_set_bitmap_ops(), and create sysfs entries
after bitmap is created.
2) split bitmap/location out as the common bitmap groups, and convert bitmap filed groups
to struct attribute_group **groups;
3) add a separate bitmap_ops for none bitmap, location_store() can be similar to
patch 3 in your set, just create/remove additional internal_bitmap_group.

> Su Yue (5):
>    md/md-bitmap: call md_bitmap_create,destroy in location_store
>    md/md-bitmap: add an extra sysfs argument to md_bitmap_create and
>      destroy
>    md/md-bitmap: add dummy bitmap ops for none to fix wrong bitmap offset
>    md: skip ID_BITMAP_NONE when show available bitmap types
>    md/md-bitmap: remove member group from bitmap_operations
>
>   drivers/md/md-bitmap.c   | 121 ++++++++++++++++++++++++++++++++++++---
>   drivers/md/md-bitmap.h   |   3 +-
>   drivers/md/md-llbitmap.c |  13 ++++-
>   drivers/md/md.c          |  55 +++++++++---------
>   drivers/md/md.h          |   2 +
>   5 files changed, 155 insertions(+), 39 deletions(-)
>
-- 
Thansk,
Kuai

  parent reply	other threads:[~2026-04-21  5:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 10:26 [PATCH v2 0/5] md: bitmap grow fixes Su Yue
2026-04-07 10:26 ` [PATCH v2 1/5] md/md-bitmap: call md_bitmap_create,destroy in location_store Su Yue
2026-04-13  7:47   ` Li Nan
2026-04-13 10:18     ` Su Yue
2026-04-15 10:34   ` Xiao Ni
2026-04-16 14:08     ` Su Yue
2026-04-20  5:21       ` Xiao Ni
2026-04-21  1:26         ` Su Yue
2026-04-07 10:26 ` [PATCH v2 2/5] md/md-bitmap: add an extra sysfs argument to md_bitmap_create and destroy Su Yue
2026-04-20  5:24   ` Xiao Ni
2026-04-07 10:26 ` [PATCH v2 3/5] md/md-bitmap: add dummy bitmap ops for none to fix wrong bitmap offset Su Yue
2026-04-20  7:05   ` Xiao Ni
2026-04-21  2:29     ` Su Yue
2026-04-21  7:36       ` Xiao Ni
2026-04-21  9:21         ` Su Yue
2026-04-07 10:26 ` [PATCH v2 4/5] md: skip ID_BITMAP_NONE when show available bitmap types Su Yue
2026-04-13  8:15   ` Li Nan
2026-04-13 10:23     ` Su Yue
2026-04-07 10:26 ` [PATCH v2 5/5] md/md-bitmap: remove member group from bitmap_operations Su Yue
2026-04-16 14:10 ` [PATCH v2 0/5] md: bitmap grow fixes Su Yue
2026-04-21  5:15 ` Yu Kuai [this message]
2026-04-21  5:39   ` Su Yue

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=afb84561-e7c4-4d08-b7ca-bd20e9f8dbda@fnnas.com \
    --to=yukuai@fnnas.com \
    --cc=glass.su@suse.com \
    --cc=heming.zhao@suse.com \
    --cc=linan122@huawei.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=song@kernel.org \
    --cc=xni@redhat.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