Bug 548399
| Summary: | pvresize doesn't work with PVs of active VGs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Jonathan Barber <jonathan.barber> |
| Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 4.5.z | CC: | agk, dwysocha, heinzm, iannis, jbrassow, mbroz, prockai |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-05-17 12:09:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Running kernel is: kernel-smp-2.6.9-55.EL # uname -a Linux bw1-repo 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux This appears to solved by upgrading the kernel to kernel-smp-2.6.9-89.0.18.EL Closing accrding to comment #2. (I think that was really kernel problem, pvresize read device size using ioctl from kernel.) |
Description of problem: pvresize doesn't increase the size of disks which are members of active volume groups. Inactivating the VG allows pvresize to work correctly. Version-Release number of selected component (if applicable): The environment is VMware ESXi4 update 1, with Redhat RHEL4U5, with the latest (that I could see) LVM2 package. Packages: lvm2-2.02.42-5.el4_8.2 device-mapper-1.02.28-2.el4 kernel-2.6.9-55.EL LVM version: 2.02.42-RHEL4 (2009-06-16) Library version: 1.02.28-RHEL4 (2009-02-20) Driver version: 4.5.5 How reproducible: Always Steps to Reproduce: 1. Create a 1G VMware disk (/dev/sdc), create a PV on it, then a VG (named "test") using this PV, then a LV (named "test") in this VG, then create an ext3 FS on the LV and mount the FS. 2. Increase the size of a VMware disk from 1G to 2G 3. Rescan to make the kernel aware of the change: # echo 1 > /sys/block/sdc/device/rescan # dmesg -c SCSI device sdc: 4194304 512-byte hdwr sectors (2147 MB) sdc: cache data unavailable sdc: assuming drive cache: write through # 3. Try and resize the PV: # pvresize -dv /dev/sdc Using physical volume(s) on command line Archiving volume group "test" metadata (seqno 4). No change to size of physical volume /dev/sdc. Resizing volume "/dev/sdc" to 2096768 sectors. Updating physical volume "/dev/sdc" Creating volume group backup "/etc/lvm/backup/test" (seqno 5). Physical volume "/dev/sdc" changed 1 physical volume(s) resized / 0 physical volume(s) not resized # Actual results: The size of the PV remains the same as reported by pvdisplay/pvscan, no free extents are available to allow me to extend LVs in the VG. Expected results: The size of the PV (as reported by the LVM tools) should increase to match the size of the device. Additional info: Changing the VG status to inactive ("vgchange -a n test") and then running pvresize shows the expected results: # umount /dev/test/test # vgchange -a n test # pvresize -dv /dev/sdc Using physical volume(s) on command line Archiving volume group "test" metadata (seqno 5). Resizing physical volume /dev/sdc from 255 to 511 extents. Resizing volume "/dev/sdc" to 4193920 sectors. Updating physical volume "/dev/sdc" Creating volume group backup "/etc/lvm/backup/test" (seqno 6). Physical volume "/dev/sdc" changed 1 physical volume(s) resized / 0 physical volume(s) not resized The command "blockdev" is also reporting the incorrect size for the device until the VG is inactived, at which point it reports the correct value (as reported by /sys/block/sdc/size after the rescan).