From: Peter Rajnoha <prajnoha@redhat.com>
To: Marius Vollmer <marius.vollmer@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Identifying useable block devices
Date: Fri, 24 Jan 2014 16:02:25 +0100 [thread overview]
Message-ID: <52E28081.50308@redhat.com> (raw)
In-Reply-To: <87wqhp4f7d.fsf@red.mvo.lan>
On 01/24/2014 03:39 PM, Marius Vollmer wrote:
> Peter Rajnoha <prajnoha@redhat.com> writes:
>
>>> The flag (DM_UDEV_DISABLE_OTHER_RULES_FLAG) is here to direct
>>> udev processing to skip any scans - it's not actually saying
>>> everyone else should remove this device now. It's just saying
>>> "don't access/touch it" when this flag is set. If there was a
>>> situation where we really need to remove (deactivate) the device,
>>> we'd do that in lvm2 directly within processing of the device.
>>
>> ...simply, the event listener that gets the event with this flag
>> set should just consider this dm device as "private".
>
> Yeah, that's what treating events with the flag as a "remove" event is
> meant to accomplish.
>
> UDisks2 maintains objects on D-Bus corresponding to public udev block
> devices. When a device changes from public to private, we should remove
> the corresponding object from D-Bus. The code for that is the same as
> when UDisks2 receives a "remove" event for the device AFAICS, so we just
> jump into that code path by changing the event action early on.
Well, in that case I think it's OK to do that.
>
> The alternative is to also create D-Bus objects for private udev block
> devices, but set UDISKS_IGNORE for them (and rely on its clients to dtrt
> with that). I think that is what UDisks 1 used to do, but David has
> choosen not to do this for UDisks2. I can't really judge which approach
> is better. Do you have an opinion?
>
To be honest, I don't like the idea with setting these variables, but
there's nothing else at the moment we could use in udev...
Thing with setting variables is that we need to rely on others to properly
check this variable - and each variable coming from different subsystems has
a different name. Would be really great if we have a more decent way
how to mark devices as private where with the "private" I mean that it can
be processed only by the subsystem that claims it. This would require a
solution hardwired directly to the way the devices are presented in the system,
maybe a common sysfs variable that would be used for all... Since there
may be numerous devices for which the first ADD/CHANGE event doesn't actually
mean the device is ready for use - some have extra configuration that follows
for it to be usable (the same applies for MD, loop devices) or they just
need to be marked as private for whatever reason.
For example, even systemd tries to gather this information from various
sources and sets SYSTEMD_READY=0/1 (see also https://github.com/systemd/systemd/blob/master/rules/99-systemd.rules.in)
(unfortunately, systemd is not the only one in the world, there are alternatives,
that's why having this info directly in sysfs would make more sense as it's
global).
This change is possible, but requires everybody to gather up and agree on
common solution...
--
Peter
next prev parent reply other threads:[~2014-01-24 15:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 8:19 [linux-lvm] Identifying useable block devices Marius Vollmer
2014-01-15 15:49 ` Alasdair G Kergon
2014-01-15 16:17 ` Oliver Rath
2014-01-15 20:24 ` Anatoly Pugachev
2014-01-16 1:32 ` Paul B. Henson
2014-01-16 5:42 ` Peter Rajnoha
2014-01-16 21:03 ` Paul B. Henson
2014-01-17 7:54 ` Peter Rajnoha
2014-01-17 9:29 ` Karel Zak
2014-01-17 9:53 ` Peter Rajnoha
2014-01-16 6:04 ` Peter Rajnoha
2014-01-17 10:02 ` Marius Vollmer
2014-01-17 13:35 ` Marius Vollmer
2014-01-20 11:52 ` Peter Rajnoha
2014-01-20 11:49 ` Peter Rajnoha
2014-01-20 12:02 ` Peter Rajnoha
2014-01-22 9:23 ` Marius Vollmer
2014-01-23 11:42 ` Peter Rajnoha
2014-01-23 12:35 ` Marius Vollmer
2014-01-24 13:24 ` Peter Rajnoha
2014-01-24 13:29 ` Peter Rajnoha
2014-01-24 14:39 ` Marius Vollmer
2014-01-24 15:02 ` Peter Rajnoha [this message]
2014-01-27 7:37 ` Marius Vollmer
2014-01-24 14:50 ` Marius Vollmer
2014-01-24 15:08 ` Peter Rajnoha
2014-01-24 15:17 ` Zdenek Kabelac
2014-01-24 15:20 ` Peter Rajnoha
2014-01-22 9:02 ` Marius Vollmer
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=52E28081.50308@redhat.com \
--to=prajnoha@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=marius.vollmer@redhat.com \
/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).