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@{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

The method you're using means every extent gets listed separately in the metadata, so you'll need to prepare a lot more space for it when you run pvcreate.

Check out the --metadatasize option to pvcreate.
[NB You can't manipulate these settings yet without losing the data on the device]

[A striping implementation which lets you specify differently-sized chunks for each device, anyone?]

Alasdair

[email protected]

Alasdair G Kergon wrote:
: On Sun, Apr 18, 2004 at 08:23:03PM +0200, Jan Kasprzak wrote:
: > 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 method you're using means every extent gets listed separately in the : metadata, so you'll need to prepare a lot more space for it when you : run pvcreate.
:
: Check out the --metadatasize option to pvcreate.

Yes, this may be the problem. As I said, I am not able to test it
now. The metadata size depends on the PV size? It would be helpful if lvextend can print something about insufficient space in metadata on the PV.

Thanks for the explanation.

-Y.

| Jan "Yenya" Kasprzak  <kas@{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

Normally, no. But in your case, yes.

You could say the metadata grows with the number of lvcreate and lvextend operations necessary to generate the configuration.

Alasdair

[email protected]