[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LVM



Tom Golson wrote:
> LVM fundamentally seems to manage physical slices by their /dev/[sh]d
> device name, and not the disk id's.  Disk id's are persistent across
> path changes, but /dev/sdX id's aren't.  It seems that when a path
> change happens, multipathd increments the /dev/sdX value, so what was
> perhaps /dev/sdc is now /dev/sdd, and this just causes LVM a world of
> pain.  Mount points go read-only and you've got to unmount, vgscan,
> vgchange -a y, and then remount.

Under what conditions does a path change and how often?

With EMC's PowerPath /dev/sd{X,Y,Z} differ but it creates a virtual
device /dev/emcpowera on top of them. LUN trespassing (changing switches
or service processors within the SAN) would then change the active
device within /dev/sd{X,Y,Z} but /dev/emcpowera would remain the mounted
device. I can see /dev/emcpowera changing if I added more LUNs, but if
I'm sticking with two EMC Power devices (one for fiber the other for
SATA) and could grow them, then I don't think I'd add extra LUNs often.
That is, assuming I use LVM on a single LUN to make separate logical
volumes for /opt/zimbra/{db,index,...} and use the SAN's ability to grow
the LUN itself with lvextend to grow the desired volume.

If the device name changed on each LUN trespass that would require lots
of "vgchange -a y" interaction and be a pain. I'm wondering if it's
because of multipathd vs PowerPath or something else.

Thanks,
  John
-- 
John Fulton, Assoc. Director IT Systems, 610-330-5650
Lafayette College, 11 Pardee Dr, Easton PA 18042-1775