All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.