[linux-lvm] LVM and devices

[linux-lvm] LVM and devices

[mrharris]

I may be a day late and a dollar short here, but I experienced a problem
this morning when I added a new scsi drive to my 2.2.10 system. I know
that the os scans for devices when the system boots and assigns device
names then. Well this screwed up my volume groups because sda1 is now
sdb1, you get the idea nothing new here. I know this has been discussed
before.
In AIX new devices are assigned and that's the way it stays unless you
manually delete the device and readd it so that when one of your mirred
drives gets blown away or you add a drive the assignments are the same
(more to it than this but you get the idea).  I believe this needs to
change in linux before LVM is added to the kernel, life would be much
simpler (md is effected by this as well I beleive). LVM does need to be
there though, the old way is just that the old way. I don't know how I
would live without LVM when you manage over 200 systems.  Just my
opinion.

add LVM to 2.4 -- YES.

--
Chaos, panic, & disorder - my work here is done.

Re: [linux-lvm] LVM and devices

[Heinz Mauelshagen]

> 
> I may be a day late and a dollar short here, but I experienced a problem
> this morning when I added a new scsi drive to my 2.2.10 system. I know
> that the os scans for devices when the system boots and assigns device
> names then. Well this screwed up my volume groups because sda1 is now
> sdb1, you get the idea nothing new here. I know this has been discussed
> before.

Run vgscan and VGs should be o.k. again.

> In AIX new devices are assigned and that's the way it stays unless you
> manually delete the device and readd it so that when one of your mirred
> drives gets blown away or you add a drive the assignments are the same
> (more to it than this but you get the idea).  I believe this needs to
> change in linux before LVM is added to the kernel, life would be much
> simpler (md is effected by this as well I beleive). LVM does need to be
> there though, the old way is just that the old way. I don't know how I
> would live without LVM when you manage over 200 systems.  Just my
> opinion.
> 
> add LVM to 2.4 -- YES.
> 

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] LVM and devices

[Ryan Murray]

On Fri, Aug 27, 1999 at 09:37:13PM +0000, Heinz Mauelshagen wrote:
> Run vgscan and VGs should be o.k. again.

If your /dev is 16-aligned...Please make sure that device skipping
"optimization" is removed before being submitted to Linus!

(although that is a user-space thing that wouldn't actually go to
Linus...)

-- 
Ryan Murray (rmurray@cyberhqz.com, rmurray@glenayre.com)
Software Designer, Glenayre Technologies Inc.
The opinions expressed here are my own.

Re: [linux-lvm] LVM and devices

[Heinz Mauelshagen]

> 
> On Fri, Aug 27, 1999 at 09:37:13PM +0000, Heinz Mauelshagen wrote:
> > Run vgscan and VGs should be o.k. again.
> 
> If your /dev is 16-aligned...Please make sure that device skipping
> "optimization" is removed before being submitted to Linus!

Yes.

As you say it below:
it is a matter of userspace and _not_ kernelland.

So, Linus doesn't have to care.

I've already thrown it away in upcoming 0.8.

> 
> (although that is a user-space thing that wouldn't actually go to
> Linus...)
> 

Regards,
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] LVM and devices

[Andreas Dilger]

Heinz writes:
> > I may be a day late and a dollar short here, but I experienced a problem
> > this morning when I added a new scsi drive to my 2.2.10 system. I know
> > that the os scans for devices when the system boots and assigns device
> > names then. Well this screwed up my volume groups because sda1 is now
> > sdb1, you get the idea nothing new here. I know this has been discussed
> > before.
> 
> Run vgscan and VGs should be o.k. again.

Is it possible to integrate LVM with devfs in such a way that LVM actually
creates the devices in devfs with proper names, like in AIX?  It should be
able to identify PVs by UUID (if this is in 0.7, I haven't had a chance to
look yet).  For that matter, LVM shouldn't be tied to the /dev names of
anything, since you could just start traversing the available devices,
find a list of UUIDs that make up a VG, and not have to worry about the
/dev names of anything (nor even store them anywhere).

This would finally free us from the changes to device names that even long
SCSI names in devfs can't handle.  In AIX, you can move PVs around at will,
or move disks for a VG from one system to another, and it will re-assemble
itself, as it never uses the device names, except when showing user output.

Cheers, Andreas
-- 
Andreas Dilger  University of Calgary \ "If a man ate a pound of pasta and
                Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \  cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/      hungry?" -- Dogbert

Re: [linux-lvm] LVM and devices

[Heinz Mauelshagen]

> 
> Heinz writes:
> > > I may be a day late and a dollar short here, but I experienced a problem
> > > this morning when I added a new scsi drive to my 2.2.10 system. I know
> > > that the os scans for devices when the system boots and assigns device
> > > names then. Well this screwed up my volume groups because sda1 is now
> > > sdb1, you get the idea nothing new here. I know this has been discussed
> > > before.
> > 
> > Run vgscan and VGs should be o.k. again.
> 
> Is it possible to integrate LVM with devfs in such a way that LVM actually
> creates the devices in devfs with proper names, like in AIX?

Sure.
That's one of the future extensions.

> It should be
> able to identify PVs by UUID (if this is in 0.7,

Today it identifies PVs by  PV number/VG name  pair.
That obviously is not unique ;*)
But it's sufficient on a single computer system.

> I haven't had a chance to
> look yet).  For that matter, LVM shouldn't be tied to the /dev names of
> anything, since you could just start traversing the available devices,
> find a list of UUIDs that make up a VG, and not have to worry about the
> /dev names of anything (nor even store them anywhere).

Actually, it depends on /dev namespace today.

But the sole reason for this is perforrmance.

We could simply throw that dependency away, if we go devfs or
could live with performance impacts without devfs.

> 
> This would finally free us from the changes to device names that even long
> SCSI names in devfs can't handle.  In AIX, you can move PVs around at will,
> or move disks for a VG from one system to another, and it will re-assemble
> itself, as it never uses the device names, except when showing user output.

If you do that in Linux (vgexport/vgimport), it works too but no UUIDs
with PVs and VGs today 8*(

Regards,
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] LVM and devices

[Andreas Dilger]

Heinz writes:
> > I haven't had a chance to
> > look yet).  For that matter, LVM shouldn't be tied to the /dev names of
> > anything, since you could just start traversing the available devices,
> > find a list of UUIDs that make up a VG, and not have to worry about the
> > /dev names of anything (nor even store them anywhere).
> 
> Actually, it depends on /dev namespace today.
> 
> But the sole reason for this is perforrmance.
> 
> We could simply throw that dependency away, if we go devfs or
> could live with performance impacts without devfs.

It shouldn't be a big change to have LVM not STORE the device names in
the VGDA, and something like a pvscan is done at boot-time (after the LVM
module is loaded, if a module) to determine PV -> /dev mapping.  The LVM
kernel code would still use the device name/major+minor in memory to
access the devices, so there should be no performance impact outside a
small amount of scanning at boot time or when a new VG is imported.

Cheers, Andreas
-- 
Andreas Dilger  University of Calgary \ "If a man ate a pound of pasta and
                Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \  cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/      hungry?" -- Dogbert

Re: [linux-lvm] LVM and devices

[Heinz Mauelshagen]

> 
> Heinz writes:
> > > I haven't had a chance to
> > > look yet).  For that matter, LVM shouldn't be tied to the /dev names of
> > > anything, since you could just start traversing the available devices,
> > > find a list of UUIDs that make up a VG, and not have to worry about the
> > > /dev names of anything (nor even store them anywhere).
> > 
> > Actually, it depends on /dev namespace today.
> > 
> > But the sole reason for this is perforrmance.
> > 
> > We could simply throw that dependency away, if we go devfs or
> > could live with performance impacts without devfs.
> 
> It shouldn't be a big change to have LVM not STORE the device names in
> the VGDA,

It doesn't use a stored devices name in the PV part of the VGDA today.
The device name is inserted at PV read time (see pv_read()).

> and something like a pvscan is done at boot-time (after the LVM
> module is loaded, if a module) to determine PV -> /dev mapping.  The LVM
> kernel code would still use the device name/major+minor in memory to
> access the devices, so there should be no performance impact outside a
> small amount of scanning at boot time or when a new VG is imported.
> 

What i meant with performance impact is the longer time to scan large
/dev configurations in user space (vgscan, pvscan and friends).

Regards,
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-