RE: [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID

RE: [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID

[Jakma, Paul]

> Any solution to this problem? Where can i teach pv_get_size about
> Mylex /dev/rd? Also does it matter that I'm using devfs and hence
> have long nested /dev/ path names?
> 
> thanks,

Ok, it turns out to be related to the new devfs namespace. I grep'ed for
/dev/rd in tools/lib, and replaced the 2 occurances i found with
/dev/rd/disc0 and got LVM working.

So the problem is that the scanning functions only descend down one level.
Eg in my case the tools/lib/* routines know about /dev/rd, so only nodes in
/dev/rd will be found, which is not where they are in latest devfs.

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.

I would much prefer that LVM tools only do basic sanity-checking on the
device file, and leave as much of the namespace policy/sanity as possible up
to the administrator. As is the Unix way. If i want to change my /dev the
LVM tools should be able to handle it.

Apart from this LVM works very very nicely. (apart from small issues which
I'll send a seperate mail about). LVM turns linux into a very capable
storage server. 

Congratulations!! 

-paul jakma
paul.jakma@compaq.com
paul@clubi.ie

Re: [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID

[Heinz Mauelshagen]

> > Any solution to this problem? Where can i teach pv_get_size about
> > Mylex /dev/rd? Also does it matter that I'm using devfs and hence
> > have long nested /dev/ path names?
> > 
> > thanks,
> 
> Ok, it turns out to be related to the new devfs namespace. I grep'ed for
> /dev/rd in tools/lib, and replaced the 2 occurances i found with
> /dev/rd/disc0 and got LVM working.
> 

Yep.

> So the problem is that the scanning functions only descend down one level.
> Eg in my case the tools/lib/* routines know about /dev/rd, so only nodes in
> /dev/rd will be found, which is not where they are in latest devfs.
> 
> 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.

If you don't have devfs and you have an overpopulated /dev, it
takes to long to scan all device nodes and open them in turn.

> 
> I would much prefer that LVM tools only do basic sanity-checking on the
> device file, and leave as much of the namespace policy/sanity as possible up
> to the administrator.

Yep.
If an admin removes all uneccessary device nodes in an non devfs system ->
full scanning of /dev is o.k. like with devfs.

A disadvantage still persists: you can't count on 16 minors per disk for eg.
like you can see with DAC960 with only 8 minors per volume.
Scanning all device nodes still causes pain (s.b.).

> As is the Unix way. If i want to change my /dev the
> LVM tools should be able to handle it.

Yep.
That's why a change to use /proc/partitions is
in the current developement code.

I think we can count on the existence of /proc and can fallback
to scanning /dev, if /proc doesn't exist by accident.

> 
> Apart from this LVM works very very nicely. (apart from small issues which
> I'll send a seperate mail about). LVM turns linux into a very capable
> storage server. 
> 
> Congratulations!! 

Thanks 8-{)

Heinz

-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Systemmanagement CS-TS                           T-Nova
                                                 Entwicklungszentrum Darmstadt
Heinz Mauelshagen                                Otto-Roehm-Strasse 71c
Senior Systems Engineer                          Postfach 10 05 41
                                                 64205 Darmstadt
mge@EZ-Darmstadt.Telekom.de                      Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID

[Michael Marxmeier]

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/

RE: [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID

[Jakma, Paul]

> Yes, it's an obvious disadvantage to do this 8-{(((
> 
> The simple reason for it is performance enhancement.
> 

there had to be a reason. :)

but i can live with the performance drop - it's only going to be for things
like the startup lvm commands, and maintenance commands like pvcreate, isn't
it?

> A disadvantage still persists: you can't count on 16 minors 
> per disk for eg.
> like you can see with DAC960 with only 8 minors per volume.
> Scanning all device nodes still causes pain (s.b.).
> 

devfs would be the answer.. but that's in a bit of a political no-mans land.
:(

> Yep.
> That's why a change to use /proc/partitions is
> in the current developement code.
> 

eeekk... /proc.. no, no no. I've had too much crap with changes in format of
/proc files breaking userland tools, i hate the same to happen to LVM. I
think it would be much mroe hassle-free to just take the performance hit and
scan /dev. 

> I think we can count on the existence of /proc and can fallback
> to scanning /dev, if /proc doesn't exist by accident.
> 

ok.. sounds reasonable.

> Thanks 8-{)
> 
> Heinz
>

regards,

Paul Jakma.

Re: [linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID

[Andi Kleen]

On Wed, Jan 26, 2000 at 06:18:00PM -0000, Jakma, Paul wrote:
> > Yep.
> > That's why a change to use /proc/partitions is
> > in the current developement code.
> > 
> 
> eeekk... /proc.. no, no no. I've had too much crap with changes in format of
> /proc files breaking userland tools, i hate the same to happen to LVM. I
> think it would be much mroe hassle-free to just take the performance hit and
> scan /dev. 

Near all /proc reading programs that broke over time were due to very poorly
writen parsers. I'm sure Heinz is able to write a proper /proc parser :-)
(that checks the column titles first and uses them to find the right
column numbers, thus deals properly with added fields, not just the usual
fscanf hack) 

-Andi

[linux-lvm] 0.8i pvcreate doesn't recognise Mylex RAID

[paul]

OK, I've compiled and installed 2.2.14+0.8i+devfs 99.10, but still
pvcreate returns an error in pv_get_size when trying to init a
Mylex /dev/rd/.../partX device:

pvcreate  /dev/rd/disc0/part3
pvcreate -- ERROR -241 getting size of physical volume "/dev/rd/disc0/part3"

ls -l /dev/rd/disc0/part3
brw-------   1 root     root      48,   3 Jan  1  1970 /dev/rd/disc0/part3

Any solution to this problem? Where can i teach pv_get_size about
Mylex /dev/rd? Also does it matter that I'm using devfs and hence
have long nested /dev/ path names?

thanks,

Paul Jakma
paul@clubi.ie

---------------------------------------------