* IMSM: Drive removed during I/O is set to faulty but not removed from volume
@ 2024-07-18 14:57 Mateusz Kusiak
2024-07-18 16:41 ` Paul E Luse
2024-07-19 7:02 ` Yu Kuai
0 siblings, 2 replies; 5+ messages in thread
From: Mateusz Kusiak @ 2024-07-18 14:57 UTC (permalink / raw)
To: linux-raid
Hello,
recently we discovered an issue regarding drive removal during I/O.
Description:
Drive removed during I/O from IMSM R1D2 array is being set to faulty but is not removed from a
volume. I/O on the array hangs.
The scenario is as follows:
1. Create R1D2 IMSM array.
2. Create single partition, format it as ext4 and mount is somewhere.
3. Start multiple checksum tests processes (more on that below) and wait a while.
4. Unplug one RAID member.
About "Checksum test":
Checksum test creates ~3GB file and calculates it's checksum twice. It basically does the following:
# dd if=/proc/kcore bs=1024 count=3052871 status=none | tee <filename> | md5sum
...and then recalculates checksum to verify if it matches.
In this scenario we use it to simulate I/O, by running multiple tests.
Expected result:
Raid member is removed from the volume and the container, array continues operation on one drive.
Actual result:
Raid member is set to faulty on volume and does not disappear (it's not removed), but it is removed
from a container. I\O on mounted volume hangs.
Additional notes:
The issue reproduces on kernel-next. We bisected that potential cause of the issue might be patch
"md: use new apis to suspend array for adding/removing rdev from state_store()"
(cfa078c8b80d0daf8f2fd4a2ab8e26fa8c33bca1) as it's the first one we observe the issue on our
reproduction setup.
Having said that, we also observed the issue for example on SLES15SP6 with kernel
6.4.0-150600.10-default, which might indicate that the problem was here, but became apparent for
some reason (race-condition or something else).
I will work on simplifying the scenario and try to provide script for reproduction.
Thank,
Mateusz
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: IMSM: Drive removed during I/O is set to faulty but not removed from volume
2024-07-18 14:57 IMSM: Drive removed during I/O is set to faulty but not removed from volume Mateusz Kusiak
@ 2024-07-18 16:41 ` Paul E Luse
2024-07-19 7:02 ` Yu Kuai
1 sibling, 0 replies; 5+ messages in thread
From: Paul E Luse @ 2024-07-18 16:41 UTC (permalink / raw)
To: Mateusz Kusiak; +Cc: linux-raid
On Thu, 18 Jul 2024 16:57:03 +0200
Mateusz Kusiak <mateusz.kusiak@linux.intel.com> wrote:
> Hello,
> recently we discovered an issue regarding drive removal during I/O.
>
> Description:
> Drive removed during I/O from IMSM R1D2 array is being set to faulty
> but is not removed from a volume. I/O on the array hangs.
>
> The scenario is as follows:
> 1. Create R1D2 IMSM array.
> 2. Create single partition, format it as ext4 and mount is somewhere.
> 3. Start multiple checksum tests processes (more on that below) and
> wait a while. 4. Unplug one RAID member.
>
Thanks Mateusz, can you confirm if this is only with imsm metadata? In
other words with native metadata is this an issue or not?
-Paul
> About "Checksum test":
> Checksum test creates ~3GB file and calculates it's checksum twice.
> It basically does the following: # dd if=/proc/kcore bs=1024
> count=3052871 status=none | tee <filename> | md5sum ...and then
> recalculates checksum to verify if it matches. In this scenario we
> use it to simulate I/O, by running multiple tests.
>
> Expected result:
> Raid member is removed from the volume and the container, array
> continues operation on one drive.
>
> Actual result:
> Raid member is set to faulty on volume and does not disappear (it's
> not removed), but it is removed from a container. I\O on mounted
> volume hangs.
>
> Additional notes:
> The issue reproduces on kernel-next. We bisected that potential cause
> of the issue might be patch "md: use new apis to suspend array for
> adding/removing rdev from state_store()"
> (cfa078c8b80d0daf8f2fd4a2ab8e26fa8c33bca1) as it's the first one we
> observe the issue on our reproduction setup.
>
> Having said that, we also observed the issue for example on SLES15SP6
> with kernel 6.4.0-150600.10-default, which might indicate that the
> problem was here, but became apparent for some reason (race-condition
> or something else).
>
> I will work on simplifying the scenario and try to provide script for
> reproduction.
>
> Thank,
> Mateusz
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: IMSM: Drive removed during I/O is set to faulty but not removed from volume
2024-07-18 14:57 IMSM: Drive removed during I/O is set to faulty but not removed from volume Mateusz Kusiak
2024-07-18 16:41 ` Paul E Luse
@ 2024-07-19 7:02 ` Yu Kuai
2024-07-19 8:02 ` Mateusz Kusiak
1 sibling, 1 reply; 5+ messages in thread
From: Yu Kuai @ 2024-07-19 7:02 UTC (permalink / raw)
To: Mateusz Kusiak, linux-raid, yukuai (C), yangerkun@huawei.com
在 2024/07/18 22:57, Mateusz Kusiak 写道:
> Hello,
> recently we discovered an issue regarding drive removal during I/O.
>
> Description:
> Drive removed during I/O from IMSM R1D2 array is being set to faulty but
> is not removed from a volume. I/O on the array hangs.
>
> The scenario is as follows:
> 1. Create R1D2 IMSM array.
> 2. Create single partition, format it as ext4 and mount is somewhere.
> 3. Start multiple checksum tests processes (more on that below) and wait
> a while.
> 4. Unplug one RAID member.
>
> About "Checksum test":
> Checksum test creates ~3GB file and calculates it's checksum twice. It
> basically does the following:
> # dd if=/proc/kcore bs=1024 count=3052871 status=none | tee <filename> |
> md5sum
> ...and then recalculates checksum to verify if it matches.
> In this scenario we use it to simulate I/O, by running multiple tests.
>
> Expected result:
> Raid member is removed from the volume and the container, array
> continues operation on one drive.
>
> Actual result:
> Raid member is set to faulty on volume and does not disappear (it's not
> removed), but it is removed from a container. I\O on mounted volume hangs.
>
> Additional notes:
> The issue reproduces on kernel-next. We bisected that potential cause of
> the issue might be patch "md: use new apis to suspend array for
> adding/removing rdev from state_store()"
> (cfa078c8b80d0daf8f2fd4a2ab8e26fa8c33bca1) as it's the first one we
> observe the issue on our reproduction setup.
>
> Having said that, we also observed the issue for example on SLES15SP6
> with kernel 6.4.0-150600.10-default, which might indicate that the
> problem was here, but became apparent for some reason (race-condition or
> something else).
Hi,
With some discussion and log collection, looks like this is a deadlock
introduced by:
https://lore.kernel.org/r/20230825031622.1530464-8-yukuai1@huaweicloud.com
Root cause is that:
1) New io is blocked because array is suspended;
2) md_start_sync suspend the array, and it's waiting for inflight IO to
be done;
3) inflight IO is waiting for md_start_sync to be done, from
md_start_write->flush_work().
Can you give following patch a test?
Thanks!
Kuai
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 64693913ed18..10c2d816062a 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8668,7 +8668,6 @@ void md_write_start(struct mddev *mddev, struct
bio *bi)
BUG_ON(mddev->ro == MD_RDONLY);
if (mddev->ro == MD_AUTO_READ) {
/* need to switch to read/write */
- flush_work(&mddev->sync_work);
mddev->ro = MD_RDWR;
set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
md_wakeup_thread(mddev->thread);
>
> I will work on simplifying the scenario and try to provide script for
> reproduction.
>
> Thank,
> Mateusz
>
> .
>
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: IMSM: Drive removed during I/O is set to faulty but not removed from volume
2024-07-19 7:02 ` Yu Kuai
@ 2024-07-19 8:02 ` Mateusz Kusiak
2024-07-19 8:20 ` Yu Kuai
0 siblings, 1 reply; 5+ messages in thread
From: Mateusz Kusiak @ 2024-07-19 8:02 UTC (permalink / raw)
To: Yu Kuai, linux-raid, yukuai (C), yangerkun@huawei.com
On 19.07.2024 09:02, Yu Kuai wrote:
>
> Hi,
>
> With some discussion and log collection, looks like this is a deadlock
> introduced by:
>
> https://lore.kernel.org/r/20230825031622.1530464-8-yukuai1@huaweicloud.com
>
> Root cause is that:
>
> 1) New io is blocked because array is suspended;
> 2) md_start_sync suspend the array, and it's waiting for inflight IO to be done;
> 3) inflight IO is waiting for md_start_sync to be done, from
> md_start_write->flush_work().
>
> Can you give following patch a test?
>
> Thanks!
> Kuai
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 64693913ed18..10c2d816062a 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -8668,7 +8668,6 @@ void md_write_start(struct mddev *mddev, struct bio *bi)
> BUG_ON(mddev->ro == MD_RDONLY);
> if (mddev->ro == MD_AUTO_READ) {
> /* need to switch to read/write */
> - flush_work(&mddev->sync_work);
> mddev->ro = MD_RDWR;
> set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
> md_wakeup_thread(mddev->thread);
>
Hi Kuai,
With the patch you provided the issue still reproduces.
Thanks,
Mateusz
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: IMSM: Drive removed during I/O is set to faulty but not removed from volume
2024-07-19 8:02 ` Mateusz Kusiak
@ 2024-07-19 8:20 ` Yu Kuai
0 siblings, 0 replies; 5+ messages in thread
From: Yu Kuai @ 2024-07-19 8:20 UTC (permalink / raw)
To: Mateusz Kusiak, Yu Kuai, linux-raid, yangerkun@huawei.com,
yukuai (C)
Hi,
在 2024/07/19 16:02, Mateusz Kusiak 写道:
>
>
> On 19.07.2024 09:02, Yu Kuai wrote:
>>
>> Hi,
>>
>> With some discussion and log collection, looks like this is a deadlock
>> introduced by:
>>
>> https://lore.kernel.org/r/20230825031622.1530464-8-yukuai1@huaweicloud.com
>>
>>
>> Root cause is that:
>>
>> 1) New io is blocked because array is suspended;
>> 2) md_start_sync suspend the array, and it's waiting for inflight IO
>> to be done;
>> 3) inflight IO is waiting for md_start_sync to be done, from
>> md_start_write->flush_work().
>>
>> Can you give following patch a test?
>>
>> Thanks!
>> Kuai
>>
>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>> index 64693913ed18..10c2d816062a 100644
>> --- a/drivers/md/md.c
>> +++ b/drivers/md/md.c
>> @@ -8668,7 +8668,6 @@ void md_write_start(struct mddev *mddev, struct
>> bio *bi)
>> BUG_ON(mddev->ro == MD_RDONLY);
>> if (mddev->ro == MD_AUTO_READ) {
>> /* need to switch to read/write */
>> - flush_work(&mddev->sync_work);
>> mddev->ro = MD_RDWR;
>> set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
>> md_wakeup_thread(mddev->thread);
>>
>
> Hi Kuai,
> With the patch you provided the issue still reproduces.
Thanks for the test, then after eliminating this problem, can we collect
log with this patch?
Thanks,
Kuai
>
> Thanks,
> Mateusz
>
> .
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-07-19 8:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-18 14:57 IMSM: Drive removed during I/O is set to faulty but not removed from volume Mateusz Kusiak
2024-07-18 16:41 ` Paul E Luse
2024-07-19 7:02 ` Yu Kuai
2024-07-19 8:02 ` Mateusz Kusiak
2024-07-19 8:20 ` Yu Kuai
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox