From: Marius Vollmer <marius.vollmer@redhat.com>
To: Peter Rajnoha <prajnoha@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Identifying useable block devices
Date: Wed, 22 Jan 2014 11:23:09 +0200 [thread overview]
Message-ID: <874n4w5q0y.fsf@red.mvo.lan> (raw)
In-Reply-To: <52DD1055.5040400@redhat.com>
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?
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.
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.
(With my limited understanding, I would say that LVM2 should make the
guarantee and fix the above scenario.)
> ...the flag would be gone if you opened the LV for read-write and then
> close it - you don't even need to write anything to the LV, just open
> and close - this would fire an event that would have dropped the flag.
Thanks, that sounds like a good workaround until your fix is available
where we need it.
next prev parent reply other threads:[~2014-01-22 9:23 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 [this message]
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
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=874n4w5q0y.fsf@red.mvo.lan \
--to=marius.vollmer@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=prajnoha@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 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.