From: Jes Sorensen <jes@trained-monkey.org>
To: Nix <nix@esperi.org.uk>, Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH 3/4] mdmonitor: set small delay once
Date: Wed, 14 Oct 2020 11:35:16 -0400 [thread overview]
Message-ID: <7b4a43b2-a922-e145-104d-00b930362bf4@trained-monkey.org> (raw)
In-Reply-To: <87lfhbz33e.fsf@esperi.org.uk>
On 9/15/20 7:33 AM, Nix wrote:
> On 9 Sep 2020, Mariusz Tkaczyk uttered the following:
>
>> + /*
>> + * If mdmonitor is awaken by event, set small delay once
>> + * to deal with udev and mdadm.
>> + */
>> + if (wait_result != 0) {
>> + if (c->delay > 5)
>> + delay_for_event = 5;
>> + } else
>> + delay_for_event = c->delay;
>
> This is racy: if any delay is needed, any finite delay value will
> now and then be too short.
>
> I think this should be fixed by arranging for mdmonitor to be signalled
> when udev or whatever has finished whatever it's doing. (udev has lots
> of ways it could be asked to do that.)
>
Hi
I have applied this patch for now, since it is better than what we had.
However, I agree it would be better to do this using udev or other
signalling, so please have a look at that.
Cheers,
Jes
next prev parent reply other threads:[~2020-10-14 15:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 8:31 [PATCH 0/4] mdmonitor improvements Mariusz Tkaczyk
2020-09-09 8:31 ` [PATCH 3/4] mdmonitor: set small delay once Mariusz Tkaczyk
2020-09-15 11:33 ` Nix
2020-10-14 15:35 ` Jes Sorensen [this message]
2020-09-09 8:31 ` [PATCH 4/4] Check if other Monitor instance running before fork Mariusz Tkaczyk
2020-10-14 15:38 ` Jes Sorensen
2020-09-29 14:34 ` [PATCH 0/4] mdmonitor improvements Tkaczyk, Mariusz
2020-10-14 15:30 ` Jes Sorensen
[not found] ` <20200909083120.10396-2-mariusz.tkaczyk@intel.com>
2020-10-14 15:34 ` [PATCH 1/4] Monitor: refresh mdstat fd after select Jes Sorensen
[not found] ` <20200909083120.10396-3-mariusz.tkaczyk@intel.com>
2020-10-14 15:34 ` [PATCH 2/4] Monitor: stop notifing about containers 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=7b4a43b2-a922-e145-104d-00b930362bf4@trained-monkey.org \
--to=jes@trained-monkey.org \
--cc=linux-raid@vger.kernel.org \
--cc=mariusz.tkaczyk@intel.com \
--cc=nix@esperi.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).