[linux-lvm] lvcreate core dump on large disks, vg name corrupted.

[linux-lvm] lvcreate core dump on large disks, vg name corrupted.

[Sean Burford]

Hi,

I am attempting to use the LVM tools under Linux 2.4.9-ac14 to set up
access to a SAN.  lvcreate is seg faulting because main() is passing a
corrupted vg name to lv_create().  I suspect this is due to the large
partitions that are being dealt with (4*100G).

Using:
  LVM 1.0.1-rc2 userland tools
  The LVM kernel modules that came with the kernel.  I could not apply
the 1.0.x patches as they do not compile with the Alan Cox patches.  I
will see if the straight 2.4.9 kernel works with the AMI MegaRAID card
in the box soon, because if it does I will be able to patch the kernel
for LVM 1.0.1-rc2.

Some related output from dmesg is:
SCSI device sdh: 209715200 512-byte hdwr sectors (107374 MB)
 sdh: sdh1
SCSI device sdi: 209715200 512-byte hdwr sectors (107374 MB)
 sdi: sdi1
SCSI device sdj: 209715200 512-byte hdwr sectors (107374 MB)
 sdj: sdj1
SCSI device sdk: 209715200 512-byte hdwr sectors (107374 MB)
 sdk: sdk1
LVM version LVM 0.9.1_beta7(ish)(20 June 2001) module loaded

Following the LVM-Howto, I have configured the LVM as follows:
vgscan
pvcreate /dev/sdh1
pvcreate /dev/sdi1
pvcreate /dev/sdj1
pvcreate /dev/sdk1
vgcreate san_vg /dev/sd[hijk]1
lvcreate -v -L255000 -ndata_lv san_vg

lvcreate segfaults:
# lvcreate -v -L255000 -ndata_lv san_vg
lvcreate -- checking volume group name "san_vg"
lvcreate -- checking volume group existence
lvcreate -- checking volume group activity
lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
lvcreate -- checking stripe count
lvcreate -- checking stripe size
lvcreate -- locking logical volume manager
lvcreate -- getting volume group status from VGDA in kernel
lvcreate -- checking stripe size against volume group physical extent
size
lvcreate -- reading volume group data of "san_vg"
lvcreate -- checking logical volume maximum size
lvcreate -- checking volume group free space
lvcreate -- checking stripe count against physical volume count
lvcreate -- checking for maximum logical volume count
lvcreate -- setting up logical volume
lvcreate -- setting read ahead sectors
lvcreate -- creating logical volume VGDA in kernel
Segmentation fault (core dumped)

I recompiled it with debugging, and got the following output:

[root@backgammon tools]# gdb ./lvcreate
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run -v -L255000 -ndata_lv san_vg
Starting program: /usr/local/src/LVM/1.0.1-rc2/tools/./lvcreate -v
-L255000 -ndata_lv san_vg
lvcreate -- checking volume group name "san_vg"
lvcreate -- checking volume group existence
lvcreate -- checking volume group activity
lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
lvcreate -- checking stripe count
lvcreate -- checking stripe size
lvcreate -- locking logical volume manager
lvcreate -- getting volume group status from VGDA in kernel
lvcreate -- checking stripe size against volume group physical extent
size
lvcreate -- reading volume group data of "san_vg"
lvcreate -- checking logical volume maximum size
lvcreate -- checking volume group free space
lvcreate -- checking stripe count against physical volume count
lvcreate -- checking for maximum logical volume count
lvcreate -- setting up logical volume
lvcreate -- setting read ahead sectors
lvcreate -- creating logical volume VGDA in kernel
 
Program received signal SIGSEGV, Segmentation fault.
lv_create (vg=0x5, lv=0xbffffa14,
    lv_name=0xbffffa2c
"dûÿ¿\213ûÿ¿°ûÿ¿àûÿ¿øûÿ¿\032üÿ¿&üÿ¿0üÿ¿óýÿ¿\022þÿ¿,þÿ¿Aþÿ¿Xþÿ¿cþÿ¿\227þÿ¿¤þÿ¿¬þÿ¿¼þÿ¿Êþÿ¿Øþÿ¿éþÿ¿÷þÿ¿\002ÿÿ¿\rÿÿ¿@ÿÿ¿»ÿÿ¿")
    at lv_create_remove.c:42
42      inline int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
(gdb) bt
#0  lv_create (vg=0x5, lv=0xbffffa14,
    lv_name=0xbffffa2c
"dûÿ¿\213ûÿ¿°ûÿ¿àûÿ¿øûÿ¿\032üÿ¿&üÿ¿0üÿ¿óýÿ¿\022þÿ¿,þÿ¿Aþÿ¿Xþÿ¿cþÿ¿\227þÿ¿¤þÿ¿¬þÿ¿¼þÿ¿Êþÿ¿Øþÿ¿éþÿ¿÷þÿ¿\002ÿÿ¿\rÿÿ¿@ÿÿ¿»ÿÿ¿")
    at lv_create_remove.c:42
#1  0x0804b03d in main (argc=5, argv=0xbffffa14) at lvcreate.c:791
#2  0x4006e177 in __libc_start_main (main=0x8049390 <main>, argc=5,
    ubp_av=0xbffffa14, init=0x8048e88 <_init>, fini=0x804b4d0 <_fini>,
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffffa0c)
    at ../sysdeps/generic/libc-start.c:129

-- 
Sean Burford    x34135
ITS Systems Specialist
Adelaide University

Re: [linux-lvm] lvcreate core dump on large disks, vg name corrupted.

[svetljo]

you can not use lvm-1.0.1rc2 tools with 0.9.1beta2 code in the kernel

try to patch the kernel with the lvm code from cvs

or befor configuring the lvm code change the kernel version in the top 
Makefile
/usr/src/linux/Makefile  to 2.4.8-ac14 and after applying the patch back 
to 2.4.9-ac14
this should be working with lvm-1.0.1rc2

or use lvm-1.0, the patch applies clean to -ac kernel

Sean Burford wrote:

>Hi,
>
>I am attempting to use the LVM tools under Linux 2.4.9-ac14 to set up
>access to a SAN.  lvcreate is seg faulting because main() is passing a
>corrupted vg name to lv_create().  I suspect this is due to the large
>partitions that are being dealt with (4*100G).
>
>Using:
>  LVM 1.0.1-rc2 userland tools
>  The LVM kernel modules that came with the kernel.  I could not apply
>the 1.0.x patches as they do not compile with the Alan Cox patches.  I
>will see if the straight 2.4.9 kernel works with the AMI MegaRAID card
>in the box soon, because if it does I will be able to patch the kernel
>for LVM 1.0.1-rc2.
>
>Some related output from dmesg is:
>SCSI device sdh: 209715200 512-byte hdwr sectors (107374 MB)
> sdh: sdh1
>SCSI device sdi: 209715200 512-byte hdwr sectors (107374 MB)
> sdi: sdi1
>SCSI device sdj: 209715200 512-byte hdwr sectors (107374 MB)
> sdj: sdj1
>SCSI device sdk: 209715200 512-byte hdwr sectors (107374 MB)
> sdk: sdk1
>LVM version LVM 0.9.1_beta7(ish)(20 June 2001) module loaded
>
>Following the LVM-Howto, I have configured the LVM as follows:
>vgscan
>pvcreate /dev/sdh1
>pvcreate /dev/sdi1
>pvcreate /dev/sdj1
>pvcreate /dev/sdk1
>vgcreate san_vg /dev/sd[hijk]1
>lvcreate -v -L255000 -ndata_lv san_vg
>
>lvcreate segfaults:
># lvcreate -v -L255000 -ndata_lv san_vg
>lvcreate -- checking volume group name "san_vg"
>lvcreate -- checking volume group existence
>lvcreate -- checking volume group activity
>lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
>lvcreate -- checking stripe count
>lvcreate -- checking stripe size
>lvcreate -- locking logical volume manager
>lvcreate -- getting volume group status from VGDA in kernel
>lvcreate -- checking stripe size against volume group physical extent
>size
>lvcreate -- reading volume group data of "san_vg"
>lvcreate -- checking logical volume maximum size
>lvcreate -- checking volume group free space
>lvcreate -- checking stripe count against physical volume count
>lvcreate -- checking for maximum logical volume count
>lvcreate -- setting up logical volume
>lvcreate -- setting read ahead sectors
>lvcreate -- creating logical volume VGDA in kernel
>Segmentation fault (core dumped)
>
>I recompiled it with debugging, and got the following output:
>
>[root@backgammon tools]# gdb ./lvcreate
>GNU gdb 5.0rh-5 Red Hat Linux 7.1
>Copyright 2001 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you
>are
>welcome to change it and/or distribute copies of it under certain
>conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB.  Type "show warranty" for
>details.
>This GDB was configured as "i386-redhat-linux"...
>(gdb) run -v -L255000 -ndata_lv san_vg
>Starting program: /usr/local/src/LVM/1.0.1-rc2/tools/./lvcreate -v
>-L255000 -ndata_lv san_vg
>lvcreate -- checking volume group name "san_vg"
>lvcreate -- checking volume group existence
>lvcreate -- checking volume group activity
>lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
>lvcreate -- checking stripe count
>lvcreate -- checking stripe size
>lvcreate -- locking logical volume manager
>lvcreate -- getting volume group status from VGDA in kernel
>lvcreate -- checking stripe size against volume group physical extent
>size
>lvcreate -- reading volume group data of "san_vg"
>lvcreate -- checking logical volume maximum size
>lvcreate -- checking volume group free space
>lvcreate -- checking stripe count against physical volume count
>lvcreate -- checking for maximum logical volume count
>lvcreate -- setting up logical volume
>lvcreate -- setting read ahead sectors
>lvcreate -- creating logical volume VGDA in kernel
> 
>Program received signal SIGSEGV, Segmentation fault.
>lv_create (vg=0x5, lv=0xbffffa14,
>    lv_name=0xbffffa2c
>"d���\213���������������\032���&���0�������\022���,���A���X���c���\227�������������������������������\002���\r���@�������")
>    at lv_create_remove.c:42
>42      inline int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
>(gdb) bt
>#0  lv_create (vg=0x5, lv=0xbffffa14,
>    lv_name=0xbffffa2c
>"d���\213���������������\032���&���0�������\022���,���A���X���c���\227�������������������������������\002���\r���@�������")
>    at lv_create_remove.c:42
>#1  0x0804b03d in main (argc=5, argv=0xbffffa14) at lvcreate.c:791
>#2  0x4006e177 in __libc_start_main (main=0x8049390 <main>, argc=5,
>    ubp_av=0xbffffa14, init=0x8048e88 <_init>, fini=0x804b4d0 <_fini>,
>    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffffa0c)
>    at ../sysdeps/generic/libc-start.c:129
>

Re: [linux-lvm] lvcreate core dump on large disks, vg name corrupted.

[Sean Burford]

Hi,

I have recompiled with a clean 2.4.9 kernel, using the following
patches:
tar xIf /usr/local/src/linux-2.4.9.tar.bz2
cat /usr/local/src/bonding-2.4.9-20010920 | patch -p1  (used for
etherchannel bonding, nothing to do with filesystems)
patch -p1 <
/usr/local/src/LVM/1.0.1-rc2/PATCHES/lvm-1.0.1-rc2-2.4.9.patch
patch -p1 <
/usr/local/src/LVM/1.0.1-rc2/PATCHES/linux-2.4.9-VFS-lock.patch
I'm also using the HP lpfcdd fiberchannel module to access the SAN
storage.

dmesg now reports:
  LVM version 1.0.1-rc2(30/08/2001) module loaded

I still get segfaults from lvcreate.

And have recreated the partitions as 2*20G, and still get segfaults with
the same symptoms (lv_create() passed junk in lv_name), so disk size
does not appear to be the key.

I might try it against a couple of loopback filesystems without lpfcdd
and bonding loaded, to see if it is a problem interacting with the
lpfcdd module.  I'll try creating filesystems on the SAN LUN's/disks
first.

svetljo wrote:
> 
> you can not use lvm-1.0.1rc2 tools with 0.9.1beta2 code in the kernel
> 
> try to patch the kernel with the lvm code from cvs
> 
> or befor configuring the lvm code change the kernel version in the top
> Makefile
> /usr/src/linux/Makefile  to 2.4.8-ac14 and after applying the patch back
> to 2.4.9-ac14
> this should be working with lvm-1.0.1rc2
> 
> or use lvm-1.0, the patch applies clean to -ac kernel
> 
> Sean Burford wrote:
> 
> >Hi,
> >
> >I am attempting to use the LVM tools under Linux 2.4.9-ac14 to set up
> >access to a SAN.  lvcreate is seg faulting because main() is passing a
> >corrupted vg name to lv_create().  I suspect this is due to the large
> >partitions that are being dealt with (4*100G).
> >
> >Using:
> >  LVM 1.0.1-rc2 userland tools
> >  The LVM kernel modules that came with the kernel.  I could not apply
> >the 1.0.x patches as they do not compile with the Alan Cox patches.  I
> >will see if the straight 2.4.9 kernel works with the AMI MegaRAID card
> >in the box soon, because if it does I will be able to patch the kernel
> >for LVM 1.0.1-rc2.
> >
> >Some related output from dmesg is:
> >SCSI device sdh: 209715200 512-byte hdwr sectors (107374 MB)
> > sdh: sdh1
> >SCSI device sdi: 209715200 512-byte hdwr sectors (107374 MB)
> > sdi: sdi1
> >SCSI device sdj: 209715200 512-byte hdwr sectors (107374 MB)
> > sdj: sdj1
> >SCSI device sdk: 209715200 512-byte hdwr sectors (107374 MB)
> > sdk: sdk1
> >LVM version LVM 0.9.1_beta7(ish)(20 June 2001) module loaded
> >
> >Following the LVM-Howto, I have configured the LVM as follows:
> >vgscan
> >pvcreate /dev/sdh1
> >pvcreate /dev/sdi1
> >pvcreate /dev/sdj1
> >pvcreate /dev/sdk1
> >vgcreate san_vg /dev/sd[hijk]1
> >lvcreate -v -L255000 -ndata_lv san_vg
> >
> >lvcreate segfaults:
> ># lvcreate -v -L255000 -ndata_lv san_vg
> >lvcreate -- checking volume group name "san_vg"
> >lvcreate -- checking volume group existence
> >lvcreate -- checking volume group activity
> >lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
> >lvcreate -- checking stripe count
> >lvcreate -- checking stripe size
> >lvcreate -- locking logical volume manager
> >lvcreate -- getting volume group status from VGDA in kernel
> >lvcreate -- checking stripe size against volume group physical extent
> >size
> >lvcreate -- reading volume group data of "san_vg"
> >lvcreate -- checking logical volume maximum size
> >lvcreate -- checking volume group free space
> >lvcreate -- checking stripe count against physical volume count
> >lvcreate -- checking for maximum logical volume count
> >lvcreate -- setting up logical volume
> >lvcreate -- setting read ahead sectors
> >lvcreate -- creating logical volume VGDA in kernel
> >Segmentation fault (core dumped)
> >
> >I recompiled it with debugging, and got the following output:
> >
> >[root@backgammon tools]# gdb ./lvcreate
> >GNU gdb 5.0rh-5 Red Hat Linux 7.1
> >Copyright 2001 Free Software Foundation, Inc.
> >GDB is free software, covered by the GNU General Public License, and you
> >are
> >welcome to change it and/or distribute copies of it under certain
> >conditions.
> >Type "show copying" to see the conditions.
> >There is absolutely no warranty for GDB.  Type "show warranty" for
> >details.
> >This GDB was configured as "i386-redhat-linux"...
> >(gdb) run -v -L255000 -ndata_lv san_vg
> >Starting program: /usr/local/src/LVM/1.0.1-rc2/tools/./lvcreate -v
> >-L255000 -ndata_lv san_vg
> >lvcreate -- checking volume group name "san_vg"
> >lvcreate -- checking volume group existence
> >lvcreate -- checking volume group activity
> >lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
> >lvcreate -- checking stripe count
> >lvcreate -- checking stripe size
> >lvcreate -- locking logical volume manager
> >lvcreate -- getting volume group status from VGDA in kernel
> >lvcreate -- checking stripe size against volume group physical extent
> >size
> >lvcreate -- reading volume group data of "san_vg"
> >lvcreate -- checking logical volume maximum size
> >lvcreate -- checking volume group free space
> >lvcreate -- checking stripe count against physical volume count
> >lvcreate -- checking for maximum logical volume count
> >lvcreate -- setting up logical volume
> >lvcreate -- setting read ahead sectors
> >lvcreate -- creating logical volume VGDA in kernel
> >
> >Program received signal SIGSEGV, Segmentation fault.
> >lv_create (vg=0x5, lv=0xbffffa14,
> >    lv_name=0xbffffa2c
> >"dûÿ¿\213ûÿ¿°ûÿ¿àûÿ¿øûÿ¿\032üÿ¿&üÿ¿0üÿ¿óýÿ¿\022þÿ¿,þÿ¿Aþÿ¿Xþÿ¿cþÿ¿\227þÿ¿¤þÿ¿¬þÿ¿¼þÿ¿Êþÿ¿Øþÿ¿éþÿ¿÷þÿ¿\002ÿÿ¿\rÿÿ¿@ÿÿ¿»ÿÿ¿")
> >    at lv_create_remove.c:42
> >42      inline int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
> >(gdb) bt
> >#0  lv_create (vg=0x5, lv=0xbffffa14,
> >    lv_name=0xbffffa2c
> >"dûÿ¿\213ûÿ¿°ûÿ¿àûÿ¿øûÿ¿\032üÿ¿&üÿ¿0üÿ¿óýÿ¿\022þÿ¿,þÿ¿Aþÿ¿Xþÿ¿cþÿ¿\227þÿ¿¤þÿ¿¬þÿ¿¼þÿ¿Êþÿ¿Øþÿ¿éþÿ¿÷þÿ¿\002ÿÿ¿\rÿÿ¿@ÿÿ¿»ÿÿ¿")
> >    at lv_create_remove.c:42
> >#1  0x0804b03d in main (argc=5, argv=0xbffffa14) at lvcreate.c:791
> >#2  0x4006e177 in __libc_start_main (main=0x8049390 <main>, argc=5,
> >    ubp_av=0xbffffa14, init=0x8048e88 <_init>, fini=0x804b4d0 <_fini>,
> >    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffffa0c)
> >    at ../sysdeps/generic/libc-start.c:129
> >
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 
Sean Burford    x34135
ITS Systems Specialist
Adelaide University

Re: [linux-lvm] lvcreate core dump on large disks, vg name corrupted.

[svetljo]

>
>tar xIf /usr/local/src/linux-2.4.9.tar.bz2
>cat /usr/local/src/bonding-2.4.9-20010920 | patch -p1  (used for
>etherchannel bonding, nothing to do with filesystems)
>
you shouldn't do this

>
>patch -p1 <
>/usr/local/src/LVM/1.0.1-rc2/PATCHES/lvm-1.0.1-rc2-2.4.9.patch
>patch -p1 <
>/usr/local/src/LVM/1.0.1-rc2/PATCHES/linux-2.4.9-VFS-lock.patch
>
you should apply only the lvm-1.0.1-rc2-2.4.9.patch , but you should run
in /usr/local/src/LVM/1.0.1-rc2/  ./configure and than in PATCHES make first
every time you apply some serious patch
make combines the parts needed by your kernel from all patches in PATCHES

>
>
>And have recreated the partitions as 2*20G, and still get segfaults with
>the same symptoms (lv_create() passed junk in lv_name), so disk size
>does not appear to be the key.
>
>I might try it against a couple of loopback filesystems without lpfcdd
>and bonding loaded, to see if it is a problem interacting with the
>lpfcdd module.  I'll try creating filesystems on the SAN LUN's/disks
>first.
>
>svetljo wrote:
>
>>you can not use lvm-1.0.1rc2 tools with 0.9.1beta2 code in the kernel
>>
>>try to patch the kernel with the lvm code from cvs
>>
>>or befor configuring the lvm code change the kernel version in the top
>>Makefile
>>/usr/src/linux/Makefile  to 2.4.8-ac14 and after applying the patch back
>>to 2.4.9-ac14
>>this should be working with lvm-1.0.1rc2
>>
>>or use lvm-1.0, the patch applies clean to -ac kernel
>>
>>Sean Burford wrote:
>>
>>>Hi,
>>>
>>>I am attempting to use the LVM tools under Linux 2.4.9-ac14 to set up
>>>access to a SAN.  lvcreate is seg faulting because main() is passing a
>>>corrupted vg name to lv_create().  I suspect this is due to the large
>>>partitions that are being dealt with (4*100G).
>>>
>>>Using:
>>> LVM 1.0.1-rc2 userland tools
>>> The LVM kernel modules that came with the kernel.  I could not apply
>>>the 1.0.x patches as they do not compile with the Alan Cox patches.  I
>>>will see if the straight 2.4.9 kernel works with the AMI MegaRAID card
>>>in the box soon, because if it does I will be able to patch the kernel
>>>for LVM 1.0.1-rc2.
>>>
>>>Some related output from dmesg is:
>>>SCSI device sdh: 209715200 512-byte hdwr sectors (107374 MB)
>>>sdh: sdh1
>>>SCSI device sdi: 209715200 512-byte hdwr sectors (107374 MB)
>>>sdi: sdi1
>>>SCSI device sdj: 209715200 512-byte hdwr sectors (107374 MB)
>>>sdj: sdj1
>>>SCSI device sdk: 209715200 512-byte hdwr sectors (107374 MB)
>>>sdk: sdk1
>>>LVM version LVM 0.9.1_beta7(ish)(20 June 2001) module loaded
>>>
>>>Following the LVM-Howto, I have configured the LVM as follows:
>>>vgscan
>>>pvcreate /dev/sdh1
>>>pvcreate /dev/sdi1
>>>pvcreate /dev/sdj1
>>>pvcreate /dev/sdk1
>>>vgcreate san_vg /dev/sd[hijk]1
>>>lvcreate -v -L255000 -ndata_lv san_vg
>>>
>>>lvcreate segfaults:
>>># lvcreate -v -L255000 -ndata_lv san_vg
>>>lvcreate -- checking volume group name "san_vg"
>>>lvcreate -- checking volume group existence
>>>lvcreate -- checking volume group activity
>>>lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
>>>lvcreate -- checking stripe count
>>>lvcreate -- checking stripe size
>>>lvcreate -- locking logical volume manager
>>>lvcreate -- getting volume group status from VGDA in kernel
>>>lvcreate -- checking stripe size against volume group physical extent
>>>size
>>>lvcreate -- reading volume group data of "san_vg"
>>>lvcreate -- checking logical volume maximum size
>>>lvcreate -- checking volume group free space
>>>lvcreate -- checking stripe count against physical volume count
>>>lvcreate -- checking for maximum logical volume count
>>>lvcreate -- setting up logical volume
>>>lvcreate -- setting read ahead sectors
>>>lvcreate -- creating logical volume VGDA in kernel
>>>Segmentation fault (core dumped)
>>>
>>>I recompiled it with debugging, and got the following output:
>>>
>>>[root@backgammon tools]# gdb ./lvcreate
>>>GNU gdb 5.0rh-5 Red Hat Linux 7.1
>>>Copyright 2001 Free Software Foundation, Inc.
>>>GDB is free software, covered by the GNU General Public License, and you
>>>are
>>>welcome to change it and/or distribute copies of it under certain
>>>conditions.
>>>Type "show copying" to see the conditions.
>>>There is absolutely no warranty for GDB.  Type "show warranty" for
>>>details.
>>>This GDB was configured as "i386-redhat-linux"...
>>>(gdb) run -v -L255000 -ndata_lv san_vg
>>>Starting program: /usr/local/src/LVM/1.0.1-rc2/tools/./lvcreate -v
>>>-L255000 -ndata_lv san_vg
>>>lvcreate -- checking volume group name "san_vg"
>>>lvcreate -- checking volume group existence
>>>lvcreate -- checking volume group activity
>>>lvcreate -- checking logical volume path "/dev/san_vg/data_lv"
>>>lvcreate -- checking stripe count
>>>lvcreate -- checking stripe size
>>>lvcreate -- locking logical volume manager
>>>lvcreate -- getting volume group status from VGDA in kernel
>>>lvcreate -- checking stripe size against volume group physical extent
>>>size
>>>lvcreate -- reading volume group data of "san_vg"
>>>lvcreate -- checking logical volume maximum size
>>>lvcreate -- checking volume group free space
>>>lvcreate -- checking stripe count against physical volume count
>>>lvcreate -- checking for maximum logical volume count
>>>lvcreate -- setting up logical volume
>>>lvcreate -- setting read ahead sectors
>>>lvcreate -- creating logical volume VGDA in kernel
>>>
>>>Program received signal SIGSEGV, Segmentation fault.
>>>lv_create (vg=0x5, lv=0xbffffa14,
>>>   lv_name=0xbffffa2c
>>>"d���\213���������������\032���&���0�������\022���,���A���X���c���\227�������������������������������\002���\r���@�������")
>>>   at lv_create_remove.c:42
>>>42      inline int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
>>>(gdb) bt
>>>#0  lv_create (vg=0x5, lv=0xbffffa14,
>>>   lv_name=0xbffffa2c
>>>"d���\213���������������\032���&���0�������\022���,���A���X���c���\227�������������������������������\002���\r���@�������")
>>>   at lv_create_remove.c:42
>>>#1  0x0804b03d in main (argc=5, argv=0xbffffa14) at lvcreate.c:791
>>>#2  0x4006e177 in __libc_start_main (main=0x8049390 <main>, argc=5,
>>>   ubp_av=0xbffffa14, init=0x8048e88 <_init>, fini=0x804b4d0 <_fini>,
>>>   rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffffa0c)
>>>   at ../sysdeps/generic/libc-start.c:129
>>>
>>_______________________________________________
>>linux-lvm mailing list
>>linux-lvm@sistina.com
>>http://lists.sistina.com/mailman/listinfo/linux-lvm
>>read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>>
>

[linux-lvm] LVM deployment tips ?

[Jim Cromie]

hi lvm'rs,

Ive begun to think about really using lvm, ie to handle /home, /usr,
as well as /tmp, other mundane stuff.

This requires planning I said, then decided it was strategy;
how to use the namespaces of VGs, LVs, PVs across 3 ides?

heres some assertions, ( and wild speculations, despite my authoritative tone )
please disabuse me of any errs, wrong thinking.
who knows, maybe its a perfect what-not-to-do.


PVs reside on partitions; ex /dev/hdb2
PVs can split a hard drive by speed.

Partition speed is widely understood to vary linearly with head radius
from spindle, more area at edge can hold more data, and which is then
read/written faster.  Addition of PVs can make LV less reliable; it now
depends on continued operation of multiple disks.

an LV can have multiple PVs, and can extend and reduce the LVs
by allocating more space from the currently used PVs, or by adding
entirely new PVs.

an LV can have its PVs striped together for BW needs.
striped LVs should never use 2 PVs from same drive.
the PV-stripes used should have similar perf #s

LVs are also used to contain snapshots.  these work like
jfs in that they preserve a consistent view of a set of files,
even as other users change the 'current' copies.

snapshots are not talked about in terms of commit / rollback.
this seems unfortunate, even if to say that snapshots cant rollback.
Someday we might get such a feature - 'restore-fs-on-reboot',
but w/o the reboot.

VGs are mostly used to container-ize data ownership,
and for administrative control, backup.  Multiple VGs
are mostly used in larger installations.

Std pcs have only 4 ide drives, limiting multi-platter parallelism.
how best to use VGs here ? removable drives ?

Tuning LVs by recomposing them of different PVs
is a time-consuming process; measuring LV traffic with
lvmsadc, lvmsar requires that you have representative loads.

For example, if you balance loads to /usr, /home/httpd/docroot,
/var/log, you may fail cuz you ignored database io loads.
This is why man lvmsar says to use a cron-job, you get to
see real data, and hopefully load patterns.

putting each dir above into a striped LVs may not be beneficial,
particularly when they compete with each other for the spindle.
Such a config would serialize access to those LVs, rather than
each dir having its own spindle.

swag: lvmsar can report io loads against each PV and LV,
but not on PEs.  (PE activity wouldnt tell you much w/o
knowing the files residing there - and this would undermine
the abstraction)


are these true ? do they have any value as guidance ?

Journalling file-systems (JFS) ?

JFS seems to have a natural advantage on growable partitions.  What are the major
features of, and distinctions between; reiserfs, ext3, xfs, jffs, xyz, etc  ??

features such as transparency and auto-sync with lvextend/reduce
seem a be high priority.  Interaction-cooperation between snapshots
and jfs would be interesting.

JFS should in the end be better at journalling, can LVM be considered
jfs-lite, or perhaps jfs-block ?  This leaves out issues

even bigger swag:

fs-load-monitoring tools are / can be much better
in real JFS, as the fs can know in detail where the load is going.
However, how to create info from such data is unclear.

In contrast, LVM-sar only separates on boundaries (LVs) you create explicitly,
it doesnt do tuning & analysis for free.

It could be possible to use snapshots or similar to create monitors on directories
somewhere within a partition.  Ex; it could separately count loads to /usr, /usr/local,
even if /usr/local werent actually a different partition, by suitable setup.

lastly,

what would happen if I lvextend'd an ext2 partition ?
would an fsck fail immediately / later, or would it never see
the new space ?    Is it thus possble to create 'hidden' storage,
(similar to files in /tmp hidden when /tmp becomes mount point for /dev/hdc3 )

tia
jimc