From: Kinga Tanska <kinga.tanska@linux.intel.com>
To: Nigel Croxon <ncroxon@redhat.com>
Cc: linux-raid@vger.kernel.org, jes@trained-monkey.org,
mariusz.tkaczyk@intel.com, kinga.tanska@intel.com
Subject: Re: [PATCH] mdadm reshape hangs on external grow chunk
Date: Thu, 29 Sep 2022 11:35:21 +0200 [thread overview]
Message-ID: <20220929113521.000012af@intel.linux.com> (raw)
In-Reply-To: <20220923142635.470305-1-ncroxon@redhat.com>
On Fri, 23 Sep 2022 10:26:35 -0400
Nigel Croxon <ncroxon@redhat.com> wrote:
> After creating a raid array on top of a imsm container. Try to
> grow the chunk size and the reshape will hang with zero progress.
> The reason is the computation of sync_max_to_set value:
> if (before_data_disks <= data_disks)
> sync_max_to_set = sra->reshape_progress / data_disks;
> else
> sync_max_to_set = (sra->component_size * data_disks
> - sra->reshape_progress) / data_disks;
>
> Can produce a zero result. Which is then used to set the maximum
> sync value, causing zero progress to the reshape. The change is to
> test if the sync_max_to_set value is zero. And if so, set the sysfs
> sync_max to "max".
>
> Steps to Reproduce:
> 1. Create a container and RAID0 array
> mdadm -CR /dev/md/imsm -e imsm -n2 /dev/nvme0n1 /dev/nvme1n1
> mdadm -CR /dev/md/vol -l0 --chunk=16 -n2 /dev/nvme0n1 /dev/nvme1n1
> 2. Wait for resync
> 3. Try to grow the chunk size
> mdadm --grow /dev/md/vol --chunk=256
>
> Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
> ---
> Grow.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Grow.c b/Grow.c
> index 0f07a894..6c5021bc 100644
> --- a/Grow.c
> +++ b/Grow.c
> @@ -943,7 +943,7 @@ int start_reshape(struct mdinfo *sra, int
> already_running, if (!already_running)
> sysfs_set_num(sra, NULL, "sync_min",
> sync_max_to_set);
> - if (st->ss->external)
> + if (sync_max_to_set)
> err = err ?: sysfs_set_num(sra, NULL, "sync_max",
> sync_max_to_set); else
> err = err ?: sysfs_set_str(sra, NULL, "sync_max",
> "max");
Hi Nigel,
I was trying to retest with your patch but still have the defect. I
analyzed it and found another reason, which causes this defect. In
validate_geometry_imsm function freesize and super is being checked and
return 1 if any of those is NULL. In my opinion 0 shall be returned
here, because it is an error and reshape should be stopped here. I will
prepare proper patch and send to review immediately.
King regards,
Kinga Tanska
next prev parent reply other threads:[~2022-09-29 9:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 14:26 [PATCH] mdadm reshape hangs on external grow chunk Nigel Croxon
2022-09-29 9:35 ` Kinga Tanska [this message]
2022-11-17 14:07 ` Mariusz Tkaczyk
2023-02-01 13:37 ` Mariusz Tkaczyk
2023-03-08 19:34 ` Jes Sorensen
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=20220929113521.000012af@intel.linux.com \
--to=kinga.tanska@linux.intel.com \
--cc=jes@trained-monkey.org \
--cc=kinga.tanska@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=mariusz.tkaczyk@intel.com \
--cc=ncroxon@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.