This is a behavior that is "strange" to us mainframers. When you add more
dasd
add it to the end of the "dasd=" string, wherever you have that defined.
With linux, regardless of the physical address, the first dasd defined is
the dasda device, the second b, etc. By putting new devices at the end of
the
definition string they will take the next slot. In future systems you can
put extra addresses in the dasd= string to reserve slots for devices to
possibly be added later on.
Good Luck!
Dennis
|--------+------------------------->
| | Phil Smith III |
| | <[EMAIL PROTECTED]|
| | .com> |
| | Sent by: Linux |
| | on 390 Port |
| | <[EMAIL PROTECTED]|
| | ARIST.EDU> |
| | |
| | |
| | 06/10/2005 |
| | 07:19 AM |
| | Please respond |
| | to Linux on 390|
| | Port |
| | |
|--------+------------------------->
>---------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [email protected]
|
| cc:
|
| Subject: LVM fragility?
|
>---------------------------------------------------------------------------------------------------------------------------|
At a customer site yesterday I found something that's either an amazing
level of fragility in LVM or else I'm just not understanding it. (This is
LVM V1; I understand V2 is a complete rewrite and probably avoids this, but
that doesn't help with production on older 2.4 kernels.)
They had a logical volume created from (say) dasdt1, dasdu1, dasdv1. Then
we added a minidisk at a lower virtual address.
This "pushed" the existing minidisks "down", so the virtual devices in the
LVM were now dasdu1, dasdv1, dasdw1!
So I have several questions:
1) Have others observed this, or did we do something weird?
2) Is there an easy way to recover?
3) Is there another way to address the devices -- one of our guys suggested
/dev/dasd/4001, /dev/dasd/4002, etc. instead of /dev/dasdt1, /dev/dasdu1,
etc. (I plan to try this today, but thought I'd ask).
4) If the previous suggestion works, is there a reasonable way to change an
existing LVM from the 'old' addressing scheme to the 'new' one?
Thanks,
--
...phsiii
Phil Smith III
Levanta, Inc.
[EMAIL PROTECTED]
(703) 476-4511 (office)
(703) 568-6662 (cell)
Levanta.
Managing Data Center Scale-Out.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
