+++ This bug was initially created as a clone of Bug #477040 +++ Hitting this in 4.8 Beta too, cloning the 5.4 bug. Can we get this in too? +++ This bug was initially created as a clone of Bug #471565 +++ Usespace part, lvm2 need calculate properly sized log device Description of problem: Creation of a mirrored LV with disk log fails, if the VG extent-size is 1K (2K and bigger works as expected). Version-Release number of selected component (if applicable): $ lvm version LVM version: 2.02.32-RHEL5 (2008-03-04) Library version: 1.02.24 (2007-12-20) Driver version: 4.11.5 How reproducible: Create a volume group with extent size of 1K and a mirrored logical volume with a disk based mirror log. Steps to Reproduce: $ dd if=/dev/zero of=/test/image[1,2,3] bs=1024k count=128 $ losetup /dev/loop0 /test/image1 $ losetup /dev/loop1 /test/image2 $ losetup /dev/loop2 /test/image3 $ pvcreate /dev/loop[0,1,2] Physical volume "/dev/loop[0,1,2]" successfully created $ vgcreate -s 1K vg_mirror_test /dev/loop0 /dev/loop1 /dev/loop2 Volume group "vg_mirror_test" successfully created $ lvcreate -L 64M -m 1 -n lv_mirror1 vg_mirror_test /dev/loop0 /dev/loop1 /dev/loop2:0-0 /dev/cdrom: open failed: Read-only file system No more output shown. Actual results: dmesg and /var/log/messages shows this: === Nov 4 17:43:17 nagtest-web1 lvm[16895]: Log device, 253:2, has failed. Nov 4 17:43:17 nagtest-web1 lvm[16895]: Device failure in vg_mirror_test-lv_mirror1 Nov 4 17:43:17 nagtest-web1 lvm[16895]: WARNING: dev_open(/etc/lvm/lvm.conf) called while suspended Nov 4 17:43:16 nagtest-web1 kernel: attempt to access beyond end of device Nov 4 17:43:22 nagtest-web1 kernel: dm-2: rw=16, want=3, limit=2 Nov 4 17:43:22 nagtest-web1 kernel: device-mapper: mirror log: Failed to read header on mirror log device, 253:2 Nov 4 17:43:22 nagtest-web1 kernel: attempt to access beyond end of device Nov 4 17:43:22 nagtest-web1 kernel: dm-2: rw=17, want=3, limit=2 Nov 4 17:43:22 nagtest-web1 kernel: device-mapper: mirror log: Failed to write header on mirror log device, 253:2 Nov 4 17:43:22 nagtest-web1 kernel: device-mapper: raid1: log resume failed Nov 4 17:43:22 nagtest-web1 kernel: attempt to access beyond end of device Nov 4 17:43:22 nagtest-web1 kernel: dm-2: rw=17, want=3, limit=2 Nov 4 17:43:22 nagtest-web1 kernel: attempt to access beyond end of device Nov 4 17:43:22 nagtest-web1 kernel: dm-2: rw=17, want=3, limit=2 Nov 4 17:43:22 nagtest-web1 kernel: attempt to access beyond end of device === 'top' lists the kmirrord process with high cpu utilization: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5541 root 20 -5 0 0 0 R 95.9 0.0 12:30.75 kmirrord === The errors continue forever ... It seems that a 1K mirror log (because the size of the mirror log is equal to the size of the VG phsical extend) isn't big enough to hold the log information! Expected results: $ lvcreate -L 64M -m 1 -n lv_mirror1 vg_mirror_test /dev/loop0 /dev/loop1 /dev/loop2:0-0 /dev/cdrom: open failed: Read-only file system Logical volume "lv_mirror1" created --- Additional comment from mbroz on 2008-12-19 10:31:03 EDT --- Fixed in upstream cvs in lvm2 2.02.44, planned for inclusion in RHEL5.4.
There are two parts, one is kernel part, which fixes log device constructor to check properly for log size and prevents "access beyond end of device". Second is lvm2 part, which correctly calculates disk log size here. Please clone that bug for kernel (I think that kernel part is more important here, should be easy patch). I'll check how complicated is the lvm2 usespace part to backport...
Fixed in lvm2-2.02.42-5.el4
Fix verified in lvm2-2.02.42-5.el4. SCENARIO - [create_mirror_on_1Kextent_vg] Create a mirror on a VG with an extent size of only 1K Recreating PVs/VG with smaller (1K) extent size hayes-01: vgcreate -s 1K mirror_sanity /dev/etherd/e1.1p1 /dev/etherd/e1.1p2 /dev/etherd/e1.1p3 /dev/etherd/e1.1p4 /dev/etherd/e1.1p5 hayes-01: lvcreate -m 1 -n mirror_on_1Kextent_vg -L 20M mirror_sanity Deactivating mirror mirror_on_1Kextent_vg... and removing Restoring VG to default extent size
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0967.html