Hi Mark - I would have agreed 100% with you up until a few days ago. I
am still not sure it was LVMs fault.
There were a LOT of DASD volumes attached to this instance, and I
think I may have blown some limit somewhere.
Part of the reason there were multiple LVMs is that I had a lot of
3390-3's around, and LVM, at least at one time,
seemed to have trouble with creating volumes that were much larger
than 100gigs using 3390-3s. Fell into a
historical habit I suppose.
It worries me enough, and the fact I can duplicate it, makes me
worried enough to not want to use LVMs for a while.
I was kinda hoping someone else had ran into this, but perhaps it is
more likely I am just doing something wrong
-Paul
On Oct 30, 2009, at 1:27 AM, Mark Post wrote:
On 10/30/2009 at 1:23 AM, Paul Raulerson <[email protected]>
wrote:
-snip-
Has anyone else ran into this?
Not without some error messages and the like to go on.
LVM doesn't care about device names, or DASD address ordering, etc.
All it cares about is if it can find the UUIDs it expects for all
its PVs. Those are written on the disk volumes when pvcreate and
vgextend is done.
If it can't find all those UUIDs, then it will throw a fit. Usually
that means that a PV was added to the VG, and that volume was not
available at the next reboot. Most often that's the result of not
re-running mkinitrd and zipl. (YaST will do that for you
automatically if you use it, otherwise you have to remember to do
it. Not sure if Red Hat has a similar mechanism to keep things in
synch.)
Mark Post
