From: Peter Rajnoha <prajnoha@redhat.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Identifying useable block devices
Date: Thu, 16 Jan 2014 07:04:44 +0100 [thread overview]
Message-ID: <52D7767C.6060706@redhat.com> (raw)
In-Reply-To: <87zjmxzmga.fsf@red.mvo.lan>
On 01/15/2014 09:19 AM, Marius Vollmer wrote:
> # ls /dev/mapper/TEST-*
> /dev/mapper/TEST-pool /dev/mapper/TEST-pool_tmeta /dev/mapper/TEST-thin
> /dev/mapper/TEST-pool_tdata /dev/mapper/TEST-pool-tpool
>
> How can a program tell that only /dev/mapper/TEST-thin can really be
> used as a block device, and the rest should be ignored?
>
> Is there a way to do this by looking at "udevadm info", for example?
>
> (What seems to work is skipping all nodes that have
> DM_UDEV_IGNORE_DISK_RULES_FLAG set to true. Is this maybe even
> documented somewhere?)
Those flags were primarily targeted to direct udev processing.
But it could be used as DM_UDEV_DISABLE_DISK_RULES_FLAG should
be always set for internal devices...
This flag actually means that udev should skip scanning the device
for metadata and it should skip creating any symlinks in /dev/disk
directory - which is a directory with symlink names based on metadata
found (e.g. filesystem uuid, subsystem names etc.).
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.
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...
Anyway, the most important rule for avoiding internal devices and
using the right ones is to follow /dev/<vgname>/<lvname> existence,
as already said in this thread.
--
Peter
next prev parent reply other threads:[~2014-01-16 6:04 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 [this message]
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
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=52D7767C.6060706@redhat.com \
--to=prajnoha@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 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).