From: Gabriele Trombetti <gabriele.trombetti@itb.cnr.it>
To: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: md data-check causes soft lockup
Date: Tue, 22 Sep 2009 21:35:09 +0200 [thread overview]
Message-ID: <4AB926ED.4010900@itb.cnr.it> (raw)
In-Reply-To: <20090922151925.GA20382@cthulhu.home.robinhill.me.uk>
Robin Hill wrote:
> On Tue Sep 22, 2009 at 07:59:45AM -0700, Lee Howard wrote:
>
>
>> Majed B. wrote:
>>
>>> I must have missed that part. It may not work for your case, but worth trying.
>>>
>>> Perhaps Neil Brown, or someone involved could shed some light on this.
>>>
>>> If I remember correctly, those soft lockups were harmless anyway.
>>>
>>>
>> Not harmless for production use. Yes, data is not harmed, and yes, the
>> problem state does recover when the data-check finishes, but during the
>> data-check the system is virtually unresponsive and all other use of the
>> system is stalled.
>>
>>
> Are you sure this is caused by these soft lockups, and that you're not
> just running with too high a /sys/block/mdX/md/sync_speed_max setting?
> I've had issues with this on some servers, where the I/O demand for the
> sync/check is causing the system to become totally unresponsive.
>
That's correct for me in the sense that lowering sync_speed_max solves
the problem, see my post, however I'd call it a bug if a value of
sync_speed_max too high starves the system forever. The resync is
supposed to be less prioritarian than normal I/O disk operations, but it
doesn't happen this way. Also note that lowering the value of
stripe_cache_size also solves the problem: how would this fit into your
reasoning?
(BTW I have not checked the mentioned patch yet, I'm not sure I can do
that in a short time because our servers are into production now)
next prev parent reply other threads:[~2009-09-22 19:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-21 18:08 md data-check causes soft lockup Lee Howard
2009-09-21 18:54 ` Majed B.
2009-09-22 14:43 ` Lee Howard
2009-09-22 14:48 ` Majed B.
2009-09-22 14:59 ` Lee Howard
2009-09-22 15:13 ` Majed B.
2009-09-22 15:19 ` Robin Hill
2009-09-22 19:35 ` Gabriele Trombetti [this message]
2009-09-23 0:16 ` Majed B.
2009-09-23 1:05 ` Guy Watkins
2009-09-21 19:13 ` kwick
2009-09-25 6:54 ` Neil Brown
2009-09-25 11:01 ` kwick
2009-09-25 11:23 ` NeilBrown
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=4AB926ED.4010900@itb.cnr.it \
--to=gabriele.trombetti@itb.cnr.it \
--cc=linux-raid@vger.kernel.org \
/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.