pvmove --version pvmove: Logical Volume Manager 1.0.8 Не работает pvmove: pvmove -v /dev/sdb14 /dev/hda7 pvmove -- checking name of source physical volume "/dev/sdb14" pvmove -- locking logical volume manager pvmove -- reading data of source physical volume from "/dev/sdb14" pvmove -- checking volume group existence pvmove -- reading data of volume group "dvarc" from lvmtab pvmove -- checking volume group consistency of "dvarc" pvmove -- searching for source physical volume "/dev/sdb14" in volume group "dvarc" pvmove -- building list of possible destination physical volumes pvmove -- checking destination physical volume names in command line pvmove -- checking volume group activity pvmove -- moving physical extents in active volume group "dvarc" pvmove -- WARNING: if you lose power during the move you may need to restore your LVM metadata from backup! pvmove -- do you want to continue? [y/n] y pvmove -- starting to move extents away from physical volume "/dev/sdb14" pvmove -- checking for enough free physical extents in "dvarc" pvmove -- /dev/sdb14 [PE 0 [video [LE 7253]]] -> /dev/hda7 [PE 0] [1/1785] /dev/dvarc/group::/dev/dvarc/video: 081e 65920, 0307 65920 pvmove -- ERROR "Inappropriate ioctl for device" copying extent from "/dev/ sdb14" pvmove -- ERROR "Inappropriate ioctl for device" moving physical extents Возможная причина тут? http://www.redhat.com/archives/linux-lvm/2003-July/msg00115.html
да, чуть на забыл - 2.4.26-std-smp-alt13
вот ещё костыль предлагается: http://www.netadmintools.com/art369.html
(In reply to comment #2) > вот ещё костыль предлагается: > http://www.netadmintools.com/art369.html там предлагается собирать/ставить device-mapper, у меня libdevmapper оказался не установлен. Поставил - пока не помогло...
(In reply to comment #0) > pvmove --version > pvmove: Logical Volume Manager 1.0.8 > Не работает pvmove: > pvmove -v /dev/sdb14 /dev/hda7 > pvmove -- checking name of source physical volume "/dev/sdb14" > pvmove -- locking logical volume manager > pvmove -- reading data of source physical volume from "/dev/sdb14" > pvmove -- checking volume group existence > pvmove -- reading data of volume group "dvarc" from lvmtab > pvmove -- checking volume group consistency of "dvarc" > pvmove -- searching for source physical volume "/dev/sdb14" in volume group > "dvarc" > pvmove -- building list of possible destination physical volumes > pvmove -- checking destination physical volume names in command line > pvmove -- checking volume group activity > pvmove -- moving physical extents in active volume group "dvarc" > pvmove -- WARNING: if you lose power during the move you may need > to restore your LVM metadata from backup! > pvmove -- do you want to continue? [y/n] y > pvmove -- starting to move extents away from physical volume "/dev/sdb14" > pvmove -- checking for enough free physical extents in "dvarc" > pvmove -- /dev/sdb14 [PE 0 [video [LE 7253]]] -> /dev/hda7 [PE 0] [1/1785] > /dev/dvarc/group::/dev/dvarc/video: 081e 65920, 0307 65920 > pvmove -- ERROR "Inappropriate ioctl for device" copying extent from "/dev/ > sdb14" > > pvmove -- ERROR "Inappropriate ioctl for device" moving physical extents > > Возможная причина тут? > http://www.redhat.com/archives/linux-lvm/2003-July/msg00115.html в логах при этом Jun 5 10:40:04 xeon kernel: lvm -- lvm_chr_ioctl: unknown command 0x4004fe51
раскопки привели к неприложенному ядерному патчу; возможно заработает после приложения kernel-feat-dm, а может, помимо этого, понадобиться обновить lvm до версии 2...
Ситуация следующая: 1) В пакете lvm-1.0.8-alt1 прикладывается патч lvm-1.0.3-pvmove.patch, который добавляет в lvm поддержку нового ioctl - PE_LOCKED_COPY. Однако соответствующий патч к ядру в Master 2.4 не попал. 2) Теоретически в lvm-1.0.3-pvmove.patch была предусмотрена возможность работы и с ядрами, не поддерживающими PE_LOCKED_COPY, однако это сломано: + ret = ioctl(group, PE_LOCKED_COPY, &pe_copy_req); + if (ret < 0) + ret = -errno; + if (ret == -EINVAL) + ret = -LVM_EPV_LOCKED_COPY_EINVAL; На самом деле при вызове нереализованного ioctl возвращается код ошибки ENOTTY, а не EINVAL, в результате функция pv_locked_copy_pe() не возвращает -LVM_EPV_LOCKED_COPY_EINVAL, и не происходит переход к старому способу выполнения pvmove. Необходимо либо исправить проверку (например, на ((ret == -EINVAL) || (ret == -ENOTTY))), либо просто убрать из пакета патчи lvm-1.0.3-pvmove.patch и lvm-1.0.3-cookie.patch (этот патч правит только то, что добавил предыдущий).
оторвал патчи - работает. И чтоб мы без Сергея делали ;)
все, видимо, уже переехали на lvm2, me too