From: Kay Sievers <kay.sievers@vrfy.org>
To: Neil Brown <neilb@suse.de>
Cc: Greg KH <gregkh@suse.de>, Andrew Morton <akpm@osdl.org>,
linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 001 of 6] md: Send online/offline uevents when an md array starts/stops.
Date: Wed, 08 Nov 2006 12:14:42 +0100 [thread overview]
Message-ID: <1162984482.16735.25.camel@pim.off.vrfy.org> (raw)
In-Reply-To: <17742.32612.870346.954568@cse.unsw.edu.au>
On Mon, 2006-11-06 at 11:18 +1100, Neil Brown wrote:
> On Friday November 3, kay.sievers@vrfy.org wrote:
> > The persistent naming rules for /dev/disk/by-* are causing this. Md
> > devices will probably just get their own rules file, which will handle
> > this and which can be packaged and installed along with the md tools.
> I'm still a bit concerned about the open->add->open infinite loop.
> If anyone opens /dev/mdX while it isn't active (e.g. to check if it is
> active), that will (given a patch that I would like to include) cause
> and ADD event which will cause udev to start it's loop again.
> Can we make udev ignore ADD for md and only watch for CHANGE?
Is there a sysfs file or something similar(we could also call a md-tool)
udev could look at, before it tries to open the device? Like:
KERNEL=="md*", ATTR{state}=="active", IMPORT{program}= ...
If we currently ignore the "add" event, then we will not hook into the
coldplug logic, where "add" events are requested for all devices to do
the initial setup after bootup.
If we can't read the state of the md device, to see if it's safe to open
the device, we would need to be smarter with the coldplug logic by
requesting "change" events if necessary, or by passing a "coldplug" flag
with the synthesized event.
Thanks,
Kay
next prev parent reply other threads:[~2006-11-08 11:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-31 6:00 [PATCH 000 of 6] md: udev events and cache bypass for reads NeilBrown
2006-10-31 6:00 ` [PATCH 001 of 6] md: Send online/offline uevents when an md array starts/stops NeilBrown
2006-10-31 21:16 ` Greg KH
2006-11-02 12:13 ` Kay Sievers
2006-11-02 12:32 ` Neil Brown
2006-11-02 13:51 ` Kay Sievers
2006-11-03 6:57 ` Neil Brown
2006-11-03 8:22 ` Kay Sievers
2006-11-06 0:18 ` Neil Brown
2006-11-06 8:38 ` dean gaudet
2006-11-07 5:05 ` Neil Brown
2006-11-09 10:10 ` Michael Tokarev
2006-11-09 10:17 ` Michael Tokarev
2006-11-08 11:14 ` Kay Sievers [this message]
2006-11-09 0:17 ` Neil Brown
2006-10-31 6:00 ` [PATCH 002 of 6] md: Change lifetime rules for 'md' devices NeilBrown
2006-10-31 8:22 ` Andrew Morton
2006-10-31 9:09 ` Neil Brown
2006-10-31 9:15 ` Jens Axboe
2006-10-31 9:26 ` Neil Brown
2006-10-31 9:30 ` Jens Axboe
2006-10-31 6:00 ` [PATCH 003 of 6] md: Define raid5_mergeable_bvec NeilBrown
2006-10-31 6:01 ` [PATCH 004 of 6] md: Handle bypassing the read cache (assuming nothing fails) NeilBrown
2006-10-31 6:01 ` [PATCH 005 of 6] md: Allow reads that have bypassed the cache to be retried on failure NeilBrown
2006-10-31 6:01 ` [PATCH 006 of 6] md: Enable bypassing cache for reads NeilBrown
2006-10-31 21:15 ` [PATCH 000 of 6] md: udev events and cache bypass " Greg KH
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=1162984482.16735.25.camel@pim.off.vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=akpm@osdl.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome