[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] lvextend fails on v2 metadata



	Hello, all!

	I have probably found a bug in lvextend when using v2 metadata.
The description of the problem is quite long, I am sorry.

- The system is Fedora Core 1 on x86_64.
- LVM utils lvm2-2.00.08-5 RPM from the FC2 beta, recompiled from src.rpm
- Kernel is 2.6.5

	I have two RAID-5 volumes - /dev/md5 is about 300GB, and /dev/md6
is about 480GB. I want to join them to a single logical volume, but not
just an ordinary concatenated one, but I want to achieve at leaset some
level of interleaving. So I have ran pvcreate on both volumes, then
vgcreate data_vg /dev/md5 /dev/md6 (128MB extent size, so md5 has 2266
extents and md6 has 3725 extents), and then
lvcreate -l1 /dev/data_vg/test_lv (i.e. test_lv has only one extent).
Then I have written a simple Perl script to lvextend the test_lv volume
by 1 extent from either md5 or md6, depending on which one has the higher
fraction of free extents. This way I will get as perfect interleaving as I
can get on the PVs of different size.

	The problem is that the lvextend failed when test_lv had
1999 PEs from md5 and 3286 PEs from md6, i.e. when I was trying to
add 2000th extent from md5 to test_lv. From this point on, I could
add extents from md6 to test_lv, but not from md5.

	I have repeated this twice, and it failed on the same 2000th PE
from md5. Then I have tried the same using version 1 format of metadata,
and I have successfuly created the interleaved LV from all extents of md5
and md6. I am now running a live system on this LV, so I cannot test it
further. Hope this description helps you to find where the problem is.

	Thanks,

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
 Any compiler or language that likes to hide things like memory allocations
 behind your back just isn't a good choice for a kernel.   --Linus Torvalds

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]