LV only detected when using "lvscan -D" on amd64 kernel

Hi,

i have an amd64-based machine, upgraded from a normal one. I'm using debian, right now still the 32bit version (except for compiling the kernel).

I'm using
Linux opt 2.4.22-bk38 #4 SMP Wed Oct 22 06:44:13 UTC 2003 x86_64 GNU/Linux

using

# dmesg  | grep "LVM"
LVM version 1.0.7(28/03/2003)

The LVM consists of 4 disks, two 40GB, one 20GB and one 120GB, gives a total of roughly 220GB. All disks seem to work properly, pvscan gives

# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/hdg" of VG "fast" [115.03 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/hdf" of VG "fast" [19.16 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/hdc" of VG "fast" [38.16 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/hdd" of VG "fast" [38.16 GB / 0 free]
pvscan -- total: 4 [210.54 GB] / in use: 4 [210.54 GB] / in no VG: 0 [0]

vgscan gives

# vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "fast"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume group

so everything looks fine. The logical volume worked fine with the old kernel (2.4.20 or something like this, for ia32.).

but

# lvscan
lvscan -- no logical volumes found

and

# vgdisplay
--- Volume group ---
VG Name               fast
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                256
Cur LV                0
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                4
Act PV                4
VG Size               210.52 GB
PE Size               4 MB
Total PE              53893
Alloc PE / Size       0 / 0
Free  PE / Size       53893 / 210.52 GB
VG UUID               NiBxzC-W5zF-Mb37-5ajN-ljE9-5k53-Fzc26O

So the logical volume seems to be gone :/

HOWEVER,

# lvscan -D
lvscan -- reading all physical volumes (this may take a while...)
lvscan -- inactive          "/dev/fast/lvol1" [210.52 GB]
lvscan -- 1 logical volumes with 210.52 GB total in 1 volume group
lvscan -- 1 inactive logical volumes

and

# vgdisplay -D
--- Volume group ---
VG Name               fast
VG Access             read/write
VG Status             NOT available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                4
Act PV                4
VG Size               210.52 GB
PE Size               4 MB
Total PE              53893
Alloc PE / Size       53893 / 210.52 GB
Free  PE / Size       0 / 0
VG UUID               NiBxzC-W5zF-Mb37-5ajN-ljE9-5k53-Fzc26O

so i think there must be still some hope. Looks like the kernel LVM stuff is somehow broken. Can this be a 64bit issue? Is there anything i could test/upgrade/whatever? Do you need more outputs? Or did i simply forget to do anything?

thanks,
Felix

Felix,

this definitely looks like a 64bit ioctl related problem.
I don't have the equipment to test here so help (is external access to your machine possible ?) is needed.

Regards,
Heinz -- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Hi,

i could setup external access to the machine, but be aware that it consists of a chroot'ed 64bit hacked-together debian, so compiling something with 64bit isn't any fun at all. The 32bit userspace however is fine.

I tried to compile the lvmtools as 64bit, but the result didn't change. are there any points where i can put some debug printfs/printks in the sources to work out where it fails? I never looked at the LVM internals, so i don't know what happens where. Does the kernel space reads and parses the metadata? Or does the userspace parses it and passes it to the kernel?

Felix

User space parses and passes it via ioctls to the kernel. Please look at lvm.h for the ioctls defined and the structures involved. Grep the LVM1 library source in tools/lib/ for "ioctl" to get you started.

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Hi,

Where exactly is the LV information passed to the kernel? is it "LV_CREATE"?

The kernel seems to don't know the LV, the LV_STATUS_BYINDEX on the "/dev/fast/group" returns "No such device or address" (ENXIO) for each index, including 0, which should be the LV in question.

It looks as "lvm_do_lv_status_byindex" in the kernel returns -ENXIO because vg_ptr->lv[lv_status_byindex_req.lv_index] is zero. Where is the point where this array is written? I only found LV_CREATE, but that's only called in vgimport, vgmerge and lvcreate, so it looks as there is another place.

Can you point me in the direction?

Felix

Yes.

See lvm_do_vg_create() and lvm_do_lv_create() functions in the driver.

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Hi,

oh well, i just used 64bit versions of vgscan and vgchange, and it works then. must be definitely a 32/64bit problem. (i didn't realized that i had of course to re-run vgscan and vgchange before :/ ).

as i don't understand the 32bit->64bit ioctl wrapping (with pointers) i don't know how it is supposed to work with 32bit userspace tools. If you still want to have access to the machine, contact me.

Felix

You better do ;)
So the solution is to work in a 64bit clean kernel/tool environment.

Thanks for the offer.
We'll probably have Itaniums pretty soon.

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-