LVM help re:

Hi,

pvscan tells me which PV belongs to which VG.
But I am wondering if the information as to
"which PVwas added to the VG in which order"
can also be determined.
In case of a disaster, the first added PV would most likely contain all the information that's has been around longer (and so more important!)

Sarma

P.S: An 'ls' will not tell you in which order files/subfolders were
created, but du or tar does.

P.S: Getting used to LVM reminds me of the days of early
minivax/ultrix days (my first unix impressions), where each 'rm' and 'mv' and 'cp' command was "entered" after 10 deep breaths and 2 minutes of deep thought about what "that" command WILL do (when "entered" ofcourse!!). Not a criticism of LVM, just that the flexibility and new-ness of this concept lets one kill oneself so easily. Can't speak for the world, but I can't handle this kind of flexibilty and power.

not sure if vgdisplay -v will

you can do lvdisplay -v of a LV and have the position of each LE on which PV.

L.

Luca Berra -- [email protected]
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Hi, Uday!

Uday Bhaskar Sarma Seetamraju ([email protected]) wrote 33 lines:

There is ls -U or ls -f.

Even though it will only list 'unsortedd / in directory order' like du or tar.

-Wolfgang

I recently pulled 2.4.10, built, installed, and tested ok on a Redhat 7.1 machine.

then I activated LVM module config, applied 1.0.1-rc2 LVM patches, rebuilt,
manually corrected 3-ary max(), min() s to 2 arg version, as per

http://lists.sistina.com/pipermail/lvm-devel/2001-September/000657.html

reboot works, insmod lvm-mod installs module as expected, pvcreate, vgcreate both worked..

lvcreate segfaults however, apparently after nearly completing the LV setup.

# gdb /sbin/lvcreate
(gdb) r -d -L1000 -nVL_test VG_test
....
<55555> pv_check_new -- CALLED
<55555> pv_check_new -- LEAVING with ret: 0
<4444> pv_check_consistency -- LEAVING with ret: 0
<333> lv_check_on_pv -- LEAVING with ret: 1
<22> pv_reserve_pe -- LEAVING with ret: 0
<1> lv_setup_for_create -- pv_reserve_pe returned: 0   pe_last: 250  pe:
0
<1> lv_setup_for_create -- pe: 0
<1> lv_setup_for_create -- LEAVING with ret: 0
<1> lvm_dont_interrupt -- CALLED
<1> lvm_dont_interrupt -- LEAVING

Program received signal SIGSEGV, Segmentation fault. lv_create (vg=0x5, lv=0xbffff9f4,

    lv_name=0xbffffa0c

":ûÿ¿Rûÿ¿nûÿ¿\203ûÿ¿\233ûÿ¿½ûÿ¿Üûÿ¿èûÿ¿òûÿ¿µýÿ¿Ôýÿ¿îýÿ¿\003þÿ¿\032þÿ¿%þÿ¿0þÿ¿=þÿ¿Eþÿ¿Uþÿ¿cþÿ¿qþÿ¿\202þÿ¿\220þÿ¿²þÿ¿Ëþÿ¿Öþÿ¿áþÿ¿\024ÿÿ¿") at lv_create_remove.c:42
42 int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
(gdb) bt
#0 lv_create (vg=0x5, lv=0xbffff9f4,

    lv_name=0xbffffa0c

":ûÿ¿Rûÿ¿nûÿ¿\203ûÿ¿\233ûÿ¿½ûÿ¿Üûÿ¿èûÿ¿òûÿ¿µýÿ¿Ôýÿ¿îýÿ¿\003þÿ¿\032þÿ¿%þÿ¿0þÿ¿=þÿ¿Eþÿ¿Uþÿ¿cþÿ¿qþÿ¿\202þÿ¿\220þÿ¿²þÿ¿Ëþÿ¿Öþÿ¿áþÿ¿\024ÿÿ¿") at lv_create_remove.c:42
#1 0x0804b03d in strcpy () at ../sysdeps/generic/strcpy.c:31
#2 0x40079177 in __libc_start_main (main=0x8049390 <strcpy+384>, argc=5,
ubp_av=0xbffff9f4, init=0x8048e88 <_init>,

    fini=0x804b4d0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>,

stack_end=0xbffff9ec) at ../sysdeps/generic/libc-start.c:129 (gdb)
(gdb) list
37
38 /* internal function */
39 int lv_create_remove ( vg_t *, lv_t *, char *, int); 40
41
42 int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
43 return lv_create_remove ( vg, lv, lv_name, LV_CREATE);
44 }
45
46
(gdb)

(gdb) up
#1 0x0804b03d in strcpy () at ../sysdeps/generic/strcpy.c:31 31 ../sysdeps/generic/strcpy.c: No such file or directory.
in ../sysdeps/generic/strcpy.c

Apriori, it looks like lv_name is uninitialized. But it runs pretty far before choking.

looking deeper;

(gdb) b lv_create
(gdb) b strcpy
(gdb) r
....

<4444> lv_check_consistency_all_lv -- vg->lv[245]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[246]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[247]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[248]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[249]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[250]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[251]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[252]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[253]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[254]: 0  name: (null)

<4444> lv_check_consistency_all_lv -- LEAVING with ret: 0 <333> vg_check_consistency_with_pv_and_lv -- LEAVING with ret: 0 <22> vg_cfgrestore -- LEAVING with ret: 0
<1> lvm_tab_vg_check_exist -- before vg.pv_cur check with vg.pv_cur: 1
pv_count: 1
<22> vg_free -- CALLED
<22> vg_free -- entering PV loop
<22> vg_free -- entering LV loop
<22> vg_free -- LEAVING with ret: 0
<1> lvm_tab_vg_check_exist -- LEAVING with ret: 1
<1> vg_check_active -- CALLED with VG: VG_test
<22> vg_check_name -- CALLED with VG: VG_test
<333> lvm_check_chars -- CALLED with name: "VG_test"
<333> lvm_check_chars -- LEAVING with ret: 0
<22> vg_check_name -- LEAVING with ret: 0
<22> vg_status -- CALLED with VG: VG_test
<333> vg_check_name -- CALLED with VG: VG_test
<4444> lvm_check_chars -- CALLED with name: "VG_test" <4444> lvm_check_chars -- LEAVING with ret: 0
<333> vg_check_name -- LEAVING with ret: 0
<22> vg_status -- LEAVING with ret: 0
<1> vg_check_active -- LEAVING with ret: 1
<1> lv_check_name -- CALLED with lv_name: "/dev/VG_test/VL_test" <22> lvm_check_chars -- CALLED with name: "/dev/VG_test/VL_test" <22> lvm_check_chars -- LEAVING with ret: 0

Breakpoint 1, strcpy (dest=0xbfffecc0 "dm\001@õÚÑ\013\2137\001@0íÿ¿\020l\001@Ñ\210\004\bìq\001@ÿÿÿÿ",

    src=0xbffff650 "/dev/VG_test/VL_test") at

../sysdeps/generic/strcpy.c:34
34 ../sysdeps/generic/strcpy.c: No such file or directory.
in ../sysdeps/generic/strcpy.c
(gdb)
(gdb) frame
#0 strcpy (dest=0xbfffecc0 "dm\001@õÚÑ\013\2137\001@0íÿ¿\020l\001@Ñ\210\004\bìq\001@ÿÿÿÿ", src=0xbffff650 "/dev/VG_test/VL_test")

    at ../sysdeps/generic/strcpy.c:34

34 in ../sysdeps/generic/strcpy.c
(gdb)

so - string is initialized, at least to start

I cant get any more insight at this time, HTH

I think you are running into a problem i had. look in the archives for
mails from/to [email protected] - but i think the problem is your inline functions that lvcreate uses.

There is a patch that was recommended to me - should fix your problem i think - it is at:

http://incandescent.mp3revolution.net/lvm/inline_fix.diff

-j

yup, that did it.

after flailing with patch rejects against unknown sources, backed up and re-did tar xvfz

then the patch applied w/o rejects,
compiled w/o errors,

and lvcreate worked !

[root@groucho 1.0.1-rc2]# lvcreate -L1500 -nVL_test VG_test lvcreate -- doing automatic backup of "VG_test"
lvcreate -- logical volume "/dev/VG_test/VL_test" successfully created

[root@groucho 1.0.1-rc2]# lvscan
lvscan -- ACTIVE "/dev/VG_test/VL_test" [1.46 GB]
lvscan -- 1 logical volumes with 1.46 GB total in 1 volume group lvscan -- 1 active logical volumes

[root@groucho 1.0.1-rc2]# lvdisplay /dev/VG_test/VL_test --- Logical volume ---

LV Name                /dev/VG_test/VL_test
VG Name                VG_test
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                1.46 GB
Current LE             375
Allocated LE           375
Allocation             next free
Read ahead sectors     120
Block device           58:0

I'm using lvm 1.0.1-rc2 under kernel 2.4.9 and work fine.

When using with kernel 2.4.10 vgscan hang, running vgscan -d, the log is listed above:

<1> lvm_get_iop_version -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_get_iop_version -- AFTER ioctl ret: 0
<1> lvm_get_iop_version -- LEAVING with ret: 10
<1> lvm_lock -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING

I have two servers Dell 8450 and they have the same problem.

and no more messages

Thank's in advance

Andre

have you tried the cvs lvm-1.0.1rc2
i have it working without PBs with 2.4.10-xfs cvs kernel

I found the error, my /proc/partitions have thousands and thousands of lines!

maybe a kernel bug!

Thank's

Andre

Yes, it is. It has something to do with SCSI and modules.

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

I ran into this as well. It happened with the Alan Cox 14 patch to Linux kernel 2.4.9 when I installed a fiber channel driver (which added partitions). I patched up drivers/block/genhd.c to detect and break circular links in the partition link list, and also to refuse to add entries that where already in the list (which was successful, though not recommended). Next I used a plain kernel without the AC patch, and again the problem went away.

Are you using an otherwise unpatched kernel?

Sean Burford    x34135
ITS Systems Specialist
Adelaide University