Frank Cox wrote:
On Wed, 18 Mar 2009 12:17:13 -0700
Rick Stevens wrote:
Now, back to your question. If you REALLY want to put /dev/sdb2 into a
new volume group, first make sure none of its space is being used in
existing LVs (check the output of "lvdisplay -vm"). If it's being used,
you'll have to first shrink all the filesystems on the LV to clear the
space, then shrink the LV itself using "lvreduce" and specifying the
number of extents that are on /dev/sdb2.
I don't understand what lvdisplay -vm is telling me.
QUOTE:
[root@mutt ~]# lvdisplay -vm
Finding all logical volumes
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID yFemKc-s2bo-zZC0-cc7q-50By-4jQM-G1MsQr
LV Write Access read/write
LV Status available
# open 1
LV Size 277.28 GB
Current LE 8873
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Segments ---
Logical extent 0 to 8872:
Type linear
Physical volume /dev/sdb2
Physical extents 0 to 8872
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV UUID 6UuO4G-X2dI-LirG-HvVF-zLfz-hrYW-NYZEdN
LV Write Access read/write
LV Status available
# open 1
LV Size 1.94 GB
Current LE 62
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
--- Segments ---
Logical extent 0 to 61:
Type linear
Physical volume /dev/sdb2
Physical extents 8873 to 8934
END OF QUOTE
Notice that it's telling me about sdb2 and says nothing about sda2, which is
where my actual "in use" volume is located.
Yeah, that is curious. It sure looks like it picked up the correct LV
sizes, but the mapping is displaying incorrectly. When I mentioned
making sure none of /dev/sdb2 was being used, I was referring to the
"Segments" sections. If an LV spreads across multiple PVs, this is
where it'll be shown. The fact you caught this indicates to me that you
actually understand it better than you think! :-)
[root@mutt ~]# pvscan
PV /dev/sdb2 VG VolGroup00 lvm2 [279.25 GB / 32.00 MB free]
PV /dev/sda2 VG VolGroup00 lvm2 [465.56 GB / 32.00 MB free]
Total: 2 [744.81 GB] / in use: 2 [744.81 GB] / in no VG: 0 [0 ]
lvdisplay doesn't appear to see sda2.
I don't know if this comes back to the fact that the volume names on both sda2
and sdb2 are the same, so it's only showing me the first (or last) one that it
finds?
Uh, I don't think so. Read my comments below.
I'm wondering if I would be best off to use fdisk to nuke the thing and carry
on from there:
[root@mutt ~]# fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x5d7711f1
Device Boot Start End Blocks Id System
/dev/sda1 * 1 25 200781 83 Linux
/dev/sda2 26 60801 488183220 8e Linux LVM
Disk /dev/sdb: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00041fa1
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 25 200781 83 Linux
/dev/sdb2 26 36481 292832820 8e Linux LVM
Ah, HAH! Ok, do you want to run off the 300GB drive or the 500GB drive
when you're all done? What this is showing us now is that the LVM
that's being run now is on the 300GB drive and that is indeed /dev/sdb,
so the "lvdisplay -vm" DOES reflect reality at the moment.
Ok, so, here's what I need to know to help you sort this out:
1. Which drive do you want to be active, the 300GB or 500GB?
2. What kind of interface the drives are (IDE, SATA, SCSI)?
3. What are the drive assignments (if IDE, which is master, which is
slave, are either or both in "cable select" mode; if SCSI, which IDs
do they occupy, etc.)
Perhaps we should take this off-list--I don't know that we want to
occupy the list's bandwidth with the back-and-forth of geting this
sorted. When it's fixed, we could post a summary on what we did for
those who are interested.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@xxxxxxxx -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- The light at the end of the tunnel is really an oncoming train. -
----------------------------------------------------------------------
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
