Summary: | pvmove is unworkable | ||
---|---|---|---|
Product: | ALT Linux 2.4 | Reporter: | Alexander Volkov <vaa> |
Component: | lvm | Assignee: | Egor S. Orlov <oes> |
Status: | CLOSED FIXED | QA Contact: | Andrey Cherepanov <cas> |
Severity: | normal | ||
Priority: | P2 | CC: | vsu |
Version: | 2.4 | ||
Hardware: | all | ||
OS: | Linux |
Description
Alexander Volkov
2006-06-05 10:23:17 MSD
да, чуть на забыл - 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 |