From: Michael Marxmeier <mike@msede.com>
To: Heinz Mauelshagen <mauelsha@ez-darmstadt.telekom.de>
Cc: Jakma Paul <Paul.Jakma@compaq.com>, linux-lvm@msede.com
Subject: Re: [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID
Date: Wed, 26 Jan 2000 03:22:32 +0100 [thread overview]
Message-ID: <388E5A68.F92FFCEF@msede.com> (raw)
In-Reply-To: 200001260001.BAA19078@u9etz.ez-darmstadt.telekom.de
Heinz Mauelshagen wrote:
> > However.. this begs the question:
> >
> > Why in the name of god do the LVM tools use such elaborate and convulated
> > methods for verifying the supplied device name? LVM tools are effectively
> > tied to a very specific /dev namespace, and changing it is non-trivial.
>
> Yes, it's an obvious disadvantage to do this 8-{(((
>
> The simple reason for it is performance enhancement.
But when/how often is this information needed? As far as i can see
lvmdiskscan, vgscan, pvscan and lvscan are afftected.
The only "frequent" operation is vgscan during boot. Frequent in this
context means that it is executed once per boot and performance
should not be _that_ critical - even given a cluttered /dev.
> That's why a change to use /proc/partitions is
> in the current developement code.
Does /proc/partitions have a mapping to real (existing) device files?
Judging from the source it does not. This also does not handle cases
when loop devices are involved. So /proc/partitions could be used
to create a list of major/minor for lvm_check_dev().
I would propose to traverse the /dev directory _recursively_ and
filtering entries by major/minor (possibly obtained from
/proc/partitions
and/or /proc/devices).
This should be fast enough, remove the special meanings from device
names and take care of dynamically created device major/minors.
If /proc is not present, the hard coded list of majors could be used
as now.
Supporting devfs is another issue. AFAIR at least older versions did
no longer require major/minors so association of devices must be done
by inspecting the path? If a stat() on devfs does return a major/minor
it should not be necessary to special case it.
Michael
--
Michael Marxmeier Marxmeier Software AG
E-Mail: mike@msede.com Besenbruchstrasse 9
Phone : +49 202 2431440 42285 Wuppertal, Germany
Fax : +49 202 2431420 http://www.msede.com/
next prev parent reply other threads:[~2000-01-26 2:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-25 17:21 [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID Jakma, Paul
2000-01-26 0:01 ` Heinz Mauelshagen
2000-01-26 2:22 ` Michael Marxmeier [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-01-26 18:18 Jakma, Paul
2000-01-26 19:54 ` Andi Kleen
2000-01-21 23:21 paul
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=388E5A68.F92FFCEF@msede.com \
--to=mike@msede.com \
--cc=Paul.Jakma@compaq.com \
--cc=linux-lvm@msede.com \
--cc=mauelsha@ez-darmstadt.telekom.de \
/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.