Red Hat Bugzilla – Bug 98627
lvm's pvmove fails as kernel rejects lvm ioctl
Last modified: 2015-01-04 17:02:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030619
Description of problem:
pvmove on a member of a live volume group fails. The problem is not in the
pvmove binary or the lvm shared libs, since using the Shrike binaries on
2.4.20-20.1.2013.nptl fails as well, whereas the binaries work on Shrike's kernel.
Version-Release number of selected component (if applicable):
kernel 2.4.20-20.1.2013.nptl lvm-1.0.3-13
Steps to Reproduce:
1.pvmove -f /dev/hda1:0
Actual Results: /dev/all/group::/dev/all/shrike: 0301 8360, 2101 88309928
pvmove -- ERROR "Inappropriate ioctl for device" copying extent from "/dev/hda1"
pvmove -- ERROR "Inappropriate ioctl for device" moving physical extents
Expected Results: Same as on Shrike
The ioctl that fails is:
open("/dev/all/group", O_RDONLY) = 6
58/dev/all/group::/dev/all/shrike: 0301 8360, 2101 88309928
) = 58
ioctl(6, 0x4004fe51, 0xbff69fe0) = -1 ENOTTY (Inappropriate ioctl for device)
This ioctl is PE_LOCKED_COPY, that is gone from this newer kernel.
Still present in Severn beta1.
sct, I understand you have a patch that adds this ioctl. Would you give me a
pointer to this patch, such that I could try to merge it into the RHL kernel?
Ok, I found the patches commented out in the Severn kernel. If I were to merge
them and get them to work, is there any chance that they'll make it to the
Cambridge release, even if it doesn't make it upstream?
The 4 patchfiles that match the *lvm* glob pattern in the latest Shrike update
kernel still apply cleanly. linux-2.4.21-lvm-rwsem-irq.patch, from Taroon,
applies cleanly as well, and should probably be included. I've done a lot of
torture testing with these 5 patches applied in the Severn patch, and observed
no data corruption with pvmove, so that patch is safe. However, I observed
deadlocks while pvmoving within a RAID1 physical volume an ext3 filesystem
containing a swap file under heavy use by a highly-parallel GCC bootstrap in the
same filesystem. Without the swap file, I couldn't get the deadlock. Even with
the deadlock, the system remained responsive until I tried to swapoff the swap file.
Fixed in kernel-2.4.22-20.1.2024.2.36.nptl