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: Mon, 27 Jan 2014 09:37:56 +0200 [thread overview]
Message-ID: <8761p5q3hn.fsf@red.mvo.lan> (raw)
In-Reply-To: <52E28081.50308@redhat.com>
Peter Rajnoha <prajnoha@redhat.com> writes:
> 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.
I don't know whether it is at all feasible, but what about using
something like SUBSYSTEM="proto-block" for devices that are not general
purpose block devices (yet). For example, a device mapper node would
start out as a proto-block, and could be changed to a block via dmsetup.
That would be a fundamental change, though, and might cause more
breakage than it helps to clean things up.
> 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).
Yeah, but on the other hand, everone might have their own slight
variation on what to ignore exactly. For example, systemd seems to
ignore encrypted but unformatted block devices for some reason, while
the guy who is actually going to format them (maybe UDisks2) probably
doesn't want to ignore them.
But, yes, it would be good if everyone could start from a sane setup and
then add exceptions to it.
next prev parent reply other threads:[~2014-01-27 7:37 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
2014-01-27 7:37 ` Marius Vollmer [this message]
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=8761p5q3hn.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.