From: Dan Williams <dan.j.williams@intel.com>
To: NeilBrown <neilb@suse.de>
Cc: "Kwolek, Adam" <adam.kwolek@intel.com>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
"Neubauer, Wojciech" <Wojciech.Neubauer@intel.com>
Subject: Re: [PATCH 2/2] imsm: FIX: Be more patient during loading matadata
Date: Thu, 14 Apr 2011 01:36:00 -0700 [thread overview]
Message-ID: <4DA6B1F0.5010207@intel.com> (raw)
In-Reply-To: <20110414180846.6a71eeb9@notabene.brown>
On 4/14/2011 1:08 AM, NeilBrown wrote:
>> Why does this existing check:
>>
>> /* retry the load if we might have raced against mdmon */
>> if (err == 3&& mdmon_running(devnum))
>> for (retry = 0; retry< 3; retry++) {
>> usleep(3000);
>> err = load_and_parse_mpb(dfd, s, NULL, 1);
>> if (err != 3)
>> break;
>> }
>
> It's pretty horrible that we need to do this, isn't it?
Yes.
> Maybe we need some way to synchronise with mdmon so we *know* if we have
> raced or not.
> i.e. mdmon keeps a count of the number of times it has updated the metadata.
> We send a message to get the count, read, then get the count again.
> The request blocks while mdmon is actually writing.
> If the counts are different, we read again.
> ??
Assuming we are only racing against dirty transitions maybe it is enough
to poll md/array_state and if it signaled while reading the metadata we
likely need to try again (of course with an intervening ping_monitor)?
--
Dan
next prev parent reply other threads:[~2011-04-14 8:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 12:51 [PATCH 1/2] FIX: Use successfully loaded metadata only Adam Kwolek
2011-04-12 12:51 ` [PATCH 2/2] imsm: FIX: Be more patient during loading matadata Adam Kwolek
2011-04-13 0:44 ` Dan Williams
2011-04-13 6:40 ` Kwolek, Adam
2011-04-13 18:56 ` Dan Williams
2011-04-14 7:57 ` Kwolek, Adam
2011-04-14 8:08 ` NeilBrown
2011-04-14 8:36 ` Dan Williams [this message]
2011-04-14 7:50 ` [PATCH 1/2] FIX: Use successfully loaded metadata only 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=4DA6B1F0.5010207@intel.com \
--to=dan.j.williams@intel.com \
--cc=Wojciech.Neubauer@intel.com \
--cc=adam.kwolek@intel.com \
--cc=ed.ciechanowski@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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.