From: Marius Vollmer <marius.vollmer@redhat.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Identifying useable block devices
Date: Fri, 17 Jan 2014 12:02:38 +0200 [thread overview]
Message-ID: <87y52fdiyp.fsf@red.mvo.lan> (raw)
In-Reply-To: <87zjmxzmga.fsf@red.mvo.lan>
[ I am not subscribed, so please keep me in CC. I'll just reply to
myself, sorry for breaking the threading.
]
Peter Rajnoha wrote:
> For now, these flags are only documented directly in libdevmapper.h
> (as they were only meant to direct udev rules and these situations
> were all audited directly by communicating with other teams). I could
> probably add a few lines to the man page directly though as others
> could use this even when reading udev database...
That would be great!
> However, for your purpose, I'd better use
> DM_UDEV_DISABLE_OTHER_RULES_FLAG which just tells that everything else
> other than DM/LVM related should skip this device.
Hmm, DM_UDEV_DISABLE_OTHER_RULES_FLAG is (now) set for thin volumes, as
far as I can tell. This is what lead me down this rabbit hole in the
first place: UDisks2 _does_ ignore events for nodes with
DM_UDEV_DISABLE_OTHER_RULES_FLAG set, and since Fedora 20, this causes
it to ignore thin volumes.
The use of DM_UDEV_DISABLE_OTHER_RULES_FLAG or any other such flag in
UDisks2 looked like a ugly hack to me, so I started looking for
alternatives.
The best option seemed to be to ignore any DISABLE flag in UDisks, and
to set UDISKS_IGNORE for LVM2 block devices that do not have the
/dev/VG/LV symlink.
Now you say that DM_UDEV_DISABLE_OTHER_RULES_FLAG is actually the Right
Way, but it seems to be buggy re thin volumes. Correct?
(Of course, UDisks2 should not ignore _events_ but should ignore
_nodes_. Otherwise, it will get confused when a node acquires a DISABLE
flag later on, which happens to thin pools. What a mess! :-)
next prev parent reply other threads:[~2014-01-17 10: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 [this message]
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
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=87y52fdiyp.fsf@red.mvo.lan \
--to=marius.vollmer@redhat.com \
--cc=linux-lvm@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.