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: Thu, 23 Jan 2014 12:42:02 +0100 [thread overview]
Message-ID: <52E1000A.3060000@redhat.com> (raw)
In-Reply-To: <874n4w5q0y.fsf@red.mvo.lan>
On 01/22/2014 10:23 AM, Marius Vollmer wrote:
> Peter Rajnoha <prajnoha@redhat.com> writes:
>
>>> Thing here is that when LVs are created then at first they have this flag
>>> set until proper initialization is finished - [...]
>
> Is it guaranteed (modulo bugs) that the DM_UDEV_DISABLE_*_RULES flags
> are only ever removed from a node, and are never added to it over it's
> lifetime between add/remove events?
No, we don't have this restriction generally - when LVM command processes
a device, it can suspend or resume it or do it in a cycle while modifying
these flags based on what's actually needed to be done - whether we need
to avoid any scanning on the device in udev or not etc (but I'm not sure
at the moment we have such a sequence used anywhere, but it's possible,
there's no restriction).
>
> This isn't true right now, and UDisks fails to handle it correctly when
> a flag is added in a "change" event. I am asking to figure out where
> the fix should go.
Well, udisks should always check the DM_UDEV_DISABLE_OTHER_RULES_FLAG
and if it's set, skip its processing. It already has:
# honor the flag that device-mapper sets if the device should be ignored
ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", GOTO="udisks_end"
..in 80-udisks.rules. So it should be already following this.
>
> For example, this is what happens when creating a pool for thinly
> provisioned volumes:
>
> UDEV [2081.714175] add /devices/virtual/block/dm-1 (block)
> [...]
> DM_UDEV_DISABLE_DISK_RULES_FLAG=1
> DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
> DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
> [...]
>
> UDEV [2081.771737] change /devices/virtual/block/dm-1 (block)
> [...]
> DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
> [...]
>
> UDEV [2081.779997] change /devices/virtual/block/dm-1 (block)
> [...]
> DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
> [...]
>
> UDEV [2081.943224] change /devices/virtual/block/dm-1 (block)
> [...]
> DM_UDEV_DISABLE_DISK_RULES_FLAG=1
> DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
> DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
> DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
> [...]
>
> I.e., the flags are set, then are removed, then set again. UDisks
> ignores the change event with the flags set, and gets into an
> inconsistent state.
>
Hmm, could you please send the whole log. This is what I see on my machine:
Creating temporary and internal LV to clean up pool metadata spare LV
- one LV marked as internal with creating the /dev/vg/lvol0 symlink (dm-2)
(DM_UDEV_DISABLE_DISK_RULES and DM_UDEV_DISABLE_OTHER_RULES set)
======================================================================
UDEV [170.702190] add /devices/virtual/block/dm-2 (block)
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
UDEV [170.713968] change /devices/virtual/block/dm-2 (block)
DM_NAME=vg-lvol0
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
UDEV [170.730282] remove /devices/virtual/block/dm-2 (block)
DM_NAME=vg-lvol0
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
(dm-2 removed!)
=======================================================================
Creating the pool LV itself
- one top-level and public LV to represent the pool as a whole (dm-2 here)
(no DM_UDEV_DISABLE_* set as that's the device to be used publicly)
- one internal LV for metadata device (dm-3 here)
(DM_UDEV_DISABLE_{DISK, OTHER, SUBSYSTEM}_RULES_FLAG set
- one internal LV for data device (dm-4 here)
(DM_UDEV_DISABLE_{DISK, OTHER, SUBSYSTEM}_RULES_FLAG set
- one internal LV for pool device (dm-5 here)
(DM_UDEV_DISABLE_{DISK, OTHER, SUBSYSTEM}_RULES_FLAG set
============================
UDEV [170.743992] add /devices/virtual/block/dm-2 (block)
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
UDEV [170.771393] change /devices/virtual/block/dm-2 (block)
DM_NAME=vg-pool
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
UDEV [170.789168] add /devices/virtual/block/dm-3 (block)
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
UDEV [170.793567] add /devices/virtual/block/dm-4 (block)
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
UDEV [170.799868] add /devices/virtual/block/dm-5 (block)
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
UDEV [170.809403] change /devices/virtual/block/dm-2 (block)
DM_NAME=vg-pool
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
UDEV [170.812167] change /devices/virtual/block/dm-3 (block)
DM_NAME=vg-pool_tmeta
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
UDEV [170.814378] change /devices/virtual/block/dm-4 (block)
DM_NAME=vg-pool_tdata
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
UDEV [170.840436] change /devices/virtual/block/dm-5 (block)
DM_NAME=vg-pool-tpool
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
UDEV [170.870652] change /devices/virtual/block/dm-3 (block)
DM_NAME=vg-pool_tmeta
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
UDEV [170.871265] change /devices/virtual/block/dm-4 (block)
DM_NAME=vg-pool_tdata
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
UDEV [170.871863] change /devices/virtual/block/dm-2 (block)
DM_NAME=vg-pool
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
UDEV [170.872784] change /devices/virtual/block/dm-5 (block)
DM_NAME=vg-pool-tpool
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
Seems OK to me. But I need your full udevadm monitor log to compare...
--
Peter
next prev parent reply other threads:[~2014-01-23 11:42 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 [this message]
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
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=52E1000A.3060000@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).