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 How reproducible: Always 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 Additional info: The ioctl that fails is: open("/dev/all/group", O_RDONLY) = 6 write(1, "/dev/all/group::/dev/all/shrike:"..., 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