On 09.02.21 01:46, Guoqing Jiang wrote:
Great. I will send a formal patch with your reported-by and tested-by.
Yes, that's fine.
Thanks a lot for your help!
Donald
Thanks,
Guoqing
Hi Donald,
On 2/8/21 19:41, Donald Buczek wrote:
Dear Guoqing,
On 08.02.21 15:53, Guoqing Jiang wrote:
On 2/8/21 12:38, Donald Buczek wrote:
5. maybe don't hold reconfig_mutex when try to unregister
sync_thread, like this.
/* resync has finished, collect result */
Dear Guoqing,
On 08.02.21 15:53, Guoqing Jiang wrote:
On 2/8/21 12:38, Donald Buczek wrote:
5. maybe don't hold reconfig_mutex when try to unregister sync_thread, like
this.
/* resync has finished, collect result */
mddev_unlock(mddev);
On 2/8/21 12:38, Donald Buczek wrote:
5. maybe don't hold reconfig_mutex when try to unregister sync_thread,
like this.
/* resync has finished, collect result */
mddev_unlock(mddev);
md_unregister_thread(>sync_thread);
mddev_lock(mddev);
As above: While
On 02.02.21 16:42, Guoqing Jiang wrote:
Hi Donald,
On 1/26/21 17:05, Donald Buczek wrote:
Dear Guoqing,
On 26.01.21 15:06, Guoqing Jiang wrote:
On 1/26/21 13:58, Donald Buczek wrote:
Hmm, how about wake the waiter up in the while loop of raid5d?
@@ -6520,6 +6532,11 @@ static void
Hi Donald,
On 1/26/21 17:05, Donald Buczek wrote:
Dear Guoqing,
On 26.01.21 15:06, Guoqing Jiang wrote:
On 1/26/21 13:58, Donald Buczek wrote:
Hmm, how about wake the waiter up in the while loop of raid5d?
@@ -6520,6 +6532,11 @@ static void raid5d(struct md_thread *thread)
Dear Guoqing,
a colleague of mine was able to produce the issue inside a vm and were able to
find a procedure to run the vm into the issue within minutes (not unreliably
after hours on a physical system as before). This of course helped to pinpoint
the problem.
My current theory of what is
Dear Guoqing,
On 26.01.21 15:06, Guoqing Jiang wrote:
On 1/26/21 13:58, Donald Buczek wrote:
Hmm, how about wake the waiter up in the while loop of raid5d?
@@ -6520,6 +6532,11 @@ static void raid5d(struct md_thread *thread)
md_check_recovery(mddev);
On 1/26/21 13:58, Donald Buczek wrote:
Hmm, how about wake the waiter up in the while loop of raid5d?
@@ -6520,6 +6532,11 @@ static void raid5d(struct md_thread *thread)
md_check_recovery(mddev);
spin_lock_irq(>device_lock);
On 26.01.21 12:14, Guoqing Jiang wrote:
Hi Donald,
On 1/26/21 10:50, Donald Buczek wrote:
[...]
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 2d21c298ffa7..f40429843906 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4687,11 +4687,13 @@ action_store(struct mddev *mddev,
Hi Donald,
On 1/26/21 10:50, Donald Buczek wrote:
[...]
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 2d21c298ffa7..f40429843906 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4687,11 +4687,13 @@ action_store(struct mddev *mddev, const char
*page, size_t len)
Dear Guoqing,
On 26.01.21 01:44, Guoqing Jiang wrote:
Hi Donald,
On 1/25/21 22:32, Donald Buczek wrote:
On 25.01.21 09:54, Donald Buczek wrote:
Dear Guoqing,
a colleague of mine was able to produce the issue inside a vm and were able to
find a procedure to run the vm into the issue
Hi Donald,
On 1/25/21 22:32, Donald Buczek wrote:
On 25.01.21 09:54, Donald Buczek wrote:
Dear Guoqing,
a colleague of mine was able to produce the issue inside a vm and were
able to find a procedure to run the vm into the issue within minutes
(not unreliably after hours on a physical
On 25.01.21 09:54, Donald Buczek wrote:
Dear Guoqing,
a colleague of mine was able to produce the issue inside a vm and were able to
find a procedure to run the vm into the issue within minutes (not unreliably
after hours on a physical system as before). This of course helped to pinpoint
Dear Guoqing,
On 20.01.21 17:33, Guoqing Jiang wrote:
Hi Donald,
On 1/19/21 12:30, Donald Buczek wrote:
Dear md-raid people,
I've reported a problem in this thread in December:
"We are using raid6 on several servers. Occasionally we had failures, where a mdX_raid6 process
seems to go into
Hi Donald,
On 1/19/21 12:30, Donald Buczek wrote:
Dear md-raid people,
I've reported a problem in this thread in December:
"We are using raid6 on several servers. Occasionally we had failures,
where a mdX_raid6 process seems to go into a busy loop and all I/O to
the md device blocks. We've
Dear md-raid people,
I've reported a problem in this thread in December:
"We are using raid6 on several servers. Occasionally we had failures, where a mdX_raid6 process
seems to go into a busy loop and all I/O to the md device blocks. We've seen this on various kernel
versions." It was clear,
Dear Guoging,
I think now that this is not an issue for md. I've driven a system into that
situation again and have clear indication, that this is a problem of the member
block device driver.
With md0 in the described errornous state (md0_raid6 busy looping, echo idle >
.../sync_action
Dear Guoqing,
On 12/3/20 2:55 AM, Guoqing Jiang wrote:
Hi Donald,
On 12/2/20 18:28, Donald Buczek wrote:
Dear Guoqing,
unfortunately the patch didn't fix the problem (unless I messed it up with my
logging). This is what I used:
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@
Hi Donald,
On 12/2/20 18:28, Donald Buczek wrote:
Dear Guoqing,
unfortunately the patch didn't fix the problem (unless I messed it up
with my logging). This is what I used:
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -9305,6 +9305,14 @@ void md_check_recovery(struct mddev
Dear Guoqing,
unfortunately the patch didn't fix the problem (unless I messed it up with my
logging). This is what I used:
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -9305,6 +9305,14 @@ void md_check_recovery(struct mddev *mddev)
Am 30.11.20 um 03:06 schrieb Guoqing Jiang:
On 11/28/20 13:25, Donald Buczek wrote:
Dear Linux mdraid people,
we are using raid6 on several servers. Occasionally we had failures, where a
mdX_raid6 process seems to go into a busy loop and all I/O to the md device
blocks. We've seen this on
On 11/28/20 13:25, Donald Buczek wrote:
Dear Linux mdraid people,
we are using raid6 on several servers. Occasionally we had failures,
where a mdX_raid6 process seems to go into a busy loop and all I/O to
the md device blocks. We've seen this on various kernel versions.
The last time
Dear Linux mdraid people,
we are using raid6 on several servers. Occasionally we had failures, where a
mdX_raid6 process seems to go into a busy loop and all I/O to the md device
blocks. We've seen this on various kernel versions.
The last time this happened (in this case with Linux
24 matches
Mail list logo
