Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

Hi

a small adition i've tried to format the LV with ext2 and reiserfs, but 
it didn't worked : mkfs segfaults
a strange one : i'm able to format with IBM JFS , and i can work without 
a problem with the LV everything just to be fine with JFS

i'm currently building:
  clean 2.4.9-linus with LVM-1.0.1rc1
       2.4.9-ac5 with LVM-1.0 ( i couldn't do it with LVM-1.0.1rc1 & rc2)
       2.4.10-pre2-xfs-cvs with LVM-1.0.1rc2
to find out what is going on with ext2 reiserfs XFS ,
is the problem coming from the XFS kernel changes

 >Hi
 >i'm having a serios trouble with creating
 >a LVM over software linear RAID
 >well i created it, formated it with XFS
 >but every time i try to mount the LV mount segfaults
 >and then i can not mount any other file system ( partition, CD, ..
 >until i reboot, when i try to mount smth mount simple stop to respond
 >without an error and blocks the console
 >
 >i'm using XFS cvs kernel 2.4.9 and LVM-1.0.1rc1
 >on ABIT's BP6 2xCelleron 533 512Mb RAM
 >the drives are on onboard HPT366 controler 2xWD 30Gb 1xMaxtor 40Gb
 >
 >the LV is striped over the 3 devices of the VG
 >the VG is /dev/hdh10 /dev/md6 /dev/md7
 >/dev/md6 is linear software RAID /dev/hde6 /dev/hde12
 >/dev/md7 is linear software RAID /dev/hdg1 /dev/hdg5 /dev/hdg6 >dev/hdg11
 >
 >i posted  to the LVM-lists and there i was told
 >to try  "dmesg | ksymoops"
 >
 >and i became the folowing answer
 >
 > > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <=====
 > >
 > >> Trace; c023fa12 <__make_request+412/6d0>
 > >> Trace; c0278dcd <md_make_request+4d/80>
 > >> Trace; c027fa0f <lvm_make_request_fn+f/20>
 > >> Trace; c023fd89 <generic_make_request+b9/120>
 > >
 > >OK, so the oops is inside the RAID layer, but it may be that it is
 > >being fed bogus data from a higher layer.  Even so, it should not
 > >oops in this case.  Since XFS changes a lot of the kernel code, I
 > >would either suggest asking the XFS folks to look at this oops,
 > >or maybe on the MD RAID mailing list, as they will know more about >it.
 >
 >this is the full "dmesg | ksymoops" , i'll try to use other FS to find
 >out whether it's a problem with XFS, but i wish me not to have to use
 >other FS, i realy love XFS


Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010247
eax: 004ac1ab   ebx: 004ac1ab   ecx: 00000000   edx: 00000000
esi: d54eb320   edi: c188b928   ebp: 00958357   esp: d4eb3670
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 5536, stackpage=d4eb3000)
Stack: d54eb3e0 c023fa12 00000907 d54eb320 00000000 01c02000 c0278dcd
dcec43c0
         00000000 d54eb320 d54eb320 00000000 01c02000 c027fa0f 00000001
d54eb320
         c023fd89 c03a7254 00000000 d54eb320 00000282 00000021 00000000
00000000
Call Trace: [<c023fa12>] [<c0278dcd>] [<c027fa0f>] [<c023fd89>] [<c01a6814>]
     [<c01a6a85>] [<c01a6fc1>] [<c01a6c47>] [<c01a6990>] [<c0105dac>]
[<c0105f1c>]
     [<c02e2140>] [<c021c10a>] [<c01fe5b8>] [<c01ff2a4>] [<c01a553e>]
[<c01feb6f>]
     [<c01feed8>] [<c01fc322>] [<c0201f40>] [<c01fb8f3>] [<c0202fdf>]
[<c02026bf>]
     [<c01a60be>] [<c02026eb>] [<c021e674>] [<c020b69c>] [<c020b843>]
[<c020b871>]
     [<c021cf48>] [<c01294e0>] [<c0125f0e>] [<c0125d9d>] [<c013cd72>]
[<c013d01b>]
     [<c013dafc>] [<c01131e0>] [<c010724c>] [<c013dd56>] [<c013dbfc>]
[<c013de13>]
     [<c010715b>]
Code: f7 f9 85 d2 74 24 55 51 68 c0 03 9c e2 e8 58 6c 75 dd 6a 00

   >>EIP; e29c0266 <[linear]linear_make_request+36/f0>   <=====
Trace; c023fa12 <__make_request+412/6d0>
Trace; c0278dcd <md_make_request+4d/80>
Trace; c027fa0f <lvm_make_request_fn+f/20>
Trace; c023fd89 <generic_make_request+b9/120>
Trace; c01a6814 <_pagebuf_page_io+1f4/370>
Trace; c01a6a85 <_page_buf_page_apply+f5/1c0>
Trace; c01a6fc1 <pagebuf_segment_apply+b1/e0>
Trace; c01a6c47 <pagebuf_iorequest+f7/160>
Trace; c01a6990 <_page_buf_page_apply+0/1c0>
Trace; c0105dac <__down+bc/d0>
Trace; c0105f1c <__down_failed+8/c>
Trace; c02e2140 <stext_lock+45b4/99d6>
Trace; c021c10a <xfsbdstrat+3a/40>
Trace; c01fe5b8 <xlog_bread+48/80>
Trace; c01ff2a4 <xlog_find_zeroed+94/1e0>
Trace; c01a553e <_pagebuf_get_object+3e/170>
Trace; c01feb6f <xlog_find_head+1f/370>
Trace; c01feed8 <xlog_find_tail+18/350>
Trace; c01fc322 <xlog_alloc_log+2a2/2e0>
Trace; c0201f40 <xlog_recover+20/c0>
Trace; c01fb8f3 <xfs_log_mount+73/b0>
Trace; c0202fdf <xfs_mountfs+55f/e20>
Trace; c02026bf <xfs_readsb+af/f0>
Trace; c01a60be <pagebuf_rele+3e/80>
Trace; c02026eb <xfs_readsb+db/f0>
Trace; c021e674 <kmem_alloc+e4/110>
Trace; c020b69c <xfs_cmountfs+4bc/590>
Trace; c020b843 <xfs_mount+63/70>
Trace; c020b871 <xfs_vfsmount+21/40>
Trace; c021cf48 <linvfs_read_super+188/270>
Trace; c01294e0 <filemap_nopage+2c0/410>
Trace; c0125f0e <handle_mm_fault+ce/e0>
Trace; c0125d9d <do_no_page+4d/f0>
Trace; c013cd72 <read_super+72/110>
Trace; c013d01b <get_sb_bdev+18b/1e0>
Trace; c013dafc <do_add_mount+1dc/290>
Trace; c01131e0 <do_page_fault+0/4b0>
Trace; c010724c <error_code+34/3c>
Trace; c013dd56 <do_mount+106/120>
Trace; c013dbfc <copy_mount_options+4c/a0>
Trace; c013de13 <sys_mount+a3/130>
Trace; c010715b <system_call+33/38>
Code;  e29c0266 <[linear]linear_make_request+36/f0>
00000000 <_EIP>:
Code;  e29c0266 <[linear]linear_make_request+36/f0>   <=====
     0:   f7 f9                     idiv   %ecx,%eax   <=====
Code;  e29c0268 <[linear]linear_make_request+38/f0>
     2:   85 d2                     test   %edx,%edx
Code;  e29c026a <[linear]linear_make_request+3a/f0>
     4:   74 24                     je     2a <_EIP+0x2a> e29c0290
<[linear]linear_make_request+60/f0>
Code;  e29c026c <[linear]linear_make_request+3c/f0>
     6:   55                        push   %ebp
Code;  e29c026d <[linear]linear_make_request+3d/f0>
     7:   51                        push   %ecx
Code;  e29c026e <[linear]linear_make_request+3e/f0>
     8:   68 c0 03 9c e2            push   $0xe29c03c0
Code;  e29c0273 <[linear]linear_make_request+43/f0>
     d:   e8 58 6c 75 dd            call   dd756c6a <_EIP+0xdd756c6a>
c0116ed0 <printk+0/1a0>
Code;  e29c0278 <[linear]linear_make_request+48/f0>
    12:   6a 00                     push   $0x0

Andreas Dilger wrote:

  >On Aug 31, 2001  15:08 +0200, svetljo wrote:
  >
  >>[root@svetljo mnt]# mount -t xfs /dev/myData/Music music
  >>Segmentation fault
  >>
  >
  >Generally this is a bad sign.  Either mount is segfaulting (unlikely)
  >or you are getting an oops in the kernel.  You need do run something
  >like "dmesg | ksymoops" in order to get some useful data about where
  >the problem is (could be xfs, LVM, or elsewhere in the kernel).
  >
  >Once you have an oops, you are best off rebooting the system, because
  >your kernel memory may be corrupted, and cause more oopses which do
  >not mean anything.  If you look in /var/log/messages (or 
/var/log/kern.log
  >or some other place, depending on where kernel messages go), you can
  >decode the FIRST oops in the log with ksymoops.  All subsequent ones are
  >useless.
  >
  >
  >>the LV ( lvcreate -i3 -I4 -L26G -nMusic )
  >>
  >>the VG -> myData   /dev/hdh10 /dev/linVG1/linLV1 /dev/linVG2/linLV2
  >>
  >>/dev/hdh10 normal partition 14G
  >>/dev/linVG1/linLV1 ->  linear LV 14G /dev/hde6 /dev/hde12
  >>/dev/linVg2/linLV2 ->  linear LV 14G /dev/hdg1 /dev/hdg5 /dev/hdg6
/dev/hdg12
  >>
  >
  >There is absolutely no point in doing this (not that it is possible to do
  >so anyways).  First of all, striping is almost never needed "for
performance"
  >unless you are normally doing very large sequential I/Os, and even so 
most
  >disks today have very good sequential I/O rates (e.g. 15-30MB/s).
Secondly,
  >you _should_ be able to just create a single LV that is striped 
across all
  >of the PVs above.  You would likely need to build it in steps, to ensure
  >that it is striped across the disks correctly.
  >
  >Cheers, Andreas
  >

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

well i did the tests

clean Linus kernel-2.4.9  LVM-1.0.1rc1                    ext2 and 
reiserfs segfaults
clean            linux-2.4.9-ac5 LVM-1.0                        ext2 and 
reiserfs segfaults
                   | linux-2.4.10-pre2-xfs LVM-1.0.1rc2      ext2 and 
reiserfs segfaults, but xfs seems to work
                   | from SGI's cvs tree  linux-2.4-xfs taken today in 
the early morning
 
i'll try to ad IBM's JFS and try it again and i'll try bonnie on them
can you give me ideas how to stres the FS to find out whether it realy 
works with XFS and JFS

what could be wrong with ext2 and reiserfs as it works with JFS-1.0.3 
and with the latest cvs XFS      

svetljo wrote:

> Hi
>
> a small adition i've tried to format the LV with ext2 and reiserfs, 
> but it didn't worked : mkfs segfaults
> a strange one : i'm able to format with IBM JFS , and i can work 
> without a problem with the LV everything just to be fine with JFS
>
> i'm currently building:
>  clean 2.4.9-linus with LVM-1.0.1rc1
>       2.4.9-ac5 with LVM-1.0 ( i couldn't do it with LVM-1.0.1rc1 & rc2)
>       2.4.10-pre2-xfs-cvs with LVM-1.0.1rc2
> to find out what is going on with ext2 reiserfs XFS ,
> is the problem coming from the XFS kernel changes
>
> >Hi
> >i'm having a serios trouble with creating
> >a LVM over software linear RAID
> >well i created it, formated it with XFS
> >but every time i try to mount the LV mount segfaults
> >and then i can not mount any other file system ( partition, CD, ..
> >until i reboot, when i try to mount smth mount simple stop to respond
> >without an error and blocks the console
> >
> >i'm using XFS cvs kernel 2.4.9 and LVM-1.0.1rc1
> >on ABIT's BP6 2xCelleron 533 512Mb RAM
> >the drives are on onboard HPT366 controler 2xWD 30Gb 1xMaxtor 40Gb
> >
> >the LV is striped over the 3 devices of the VG
> >the VG is /dev/hdh10 /dev/md6 /dev/md7
> >/dev/md6 is linear software RAID /dev/hde6 /dev/hde12
> >/dev/md7 is linear software RAID /dev/hdg1 /dev/hdg5 /dev/hdg6 
> >dev/hdg11
> >
> >i posted  to the LVM-lists and there i was told
> >to try  "dmesg | ksymoops"
> >
> >and i became the folowing answer
> >
> > > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <=====
> > >
> > >> Trace; c023fa12 <__make_request+412/6d0>
> > >> Trace; c0278dcd <md_make_request+4d/80>
> > >> Trace; c027fa0f <lvm_make_request_fn+f/20>
> > >> Trace; c023fd89 <generic_make_request+b9/120>
> > >
> > >OK, so the oops is inside the RAID layer, but it may be that it is
> > >being fed bogus data from a higher layer.  Even so, it should not
> > >oops in this case.  Since XFS changes a lot of the kernel code, I
> > >would either suggest asking the XFS folks to look at this oops,
> > >or maybe on the MD RAID mailing list, as they will know more about 
> >it.
> >
> >this is the full "dmesg | ksymoops" , i'll try to use other FS to find
> >out whether it's a problem with XFS, but i wish me not to have to use
> >other FS, i realy love XFS
>
>
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010247
> eax: 004ac1ab   ebx: 004ac1ab   ecx: 00000000   edx: 00000000
> esi: d54eb320   edi: c188b928   ebp: 00958357   esp: d4eb3670
> ds: 0018   es: 0018   ss: 0018
> Process mount (pid: 5536, stackpage=d4eb3000)
> Stack: d54eb3e0 c023fa12 00000907 d54eb320 00000000 01c02000 c0278dcd
> dcec43c0
>         00000000 d54eb320 d54eb320 00000000 01c02000 c027fa0f 00000001
> d54eb320
>         c023fd89 c03a7254 00000000 d54eb320 00000282 00000021 00000000
> 00000000
> Call Trace: [<c023fa12>] [<c0278dcd>] [<c027fa0f>] [<c023fd89>] 
> [<c01a6814>]
>     [<c01a6a85>] [<c01a6fc1>] [<c01a6c47>] [<c01a6990>] [<c0105dac>]
> [<c0105f1c>]
>     [<c02e2140>] [<c021c10a>] [<c01fe5b8>] [<c01ff2a4>] [<c01a553e>]
> [<c01feb6f>]
>     [<c01feed8>] [<c01fc322>] [<c0201f40>] [<c01fb8f3>] [<c0202fdf>]
> [<c02026bf>]
>     [<c01a60be>] [<c02026eb>] [<c021e674>] [<c020b69c>] [<c020b843>]
> [<c020b871>]
>     [<c021cf48>] [<c01294e0>] [<c0125f0e>] [<c0125d9d>] [<c013cd72>]
> [<c013d01b>]
>     [<c013dafc>] [<c01131e0>] [<c010724c>] [<c013dd56>] [<c013dbfc>]
> [<c013de13>]
>     [<c010715b>]
> Code: f7 f9 85 d2 74 24 55 51 68 c0 03 9c e2 e8 58 6c 75 dd 6a 00
>
>   >>EIP; e29c0266 <[linear]linear_make_request+36/f0>   <=====
> Trace; c023fa12 <__make_request+412/6d0>
> Trace; c0278dcd <md_make_request+4d/80>
> Trace; c027fa0f <lvm_make_request_fn+f/20>
> Trace; c023fd89 <generic_make_request+b9/120>
> Trace; c01a6814 <_pagebuf_page_io+1f4/370>
> Trace; c01a6a85 <_page_buf_page_apply+f5/1c0>
> Trace; c01a6fc1 <pagebuf_segment_apply+b1/e0>
> Trace; c01a6c47 <pagebuf_iorequest+f7/160>
> Trace; c01a6990 <_page_buf_page_apply+0/1c0>
> Trace; c0105dac <__down+bc/d0>
> Trace; c0105f1c <__down_failed+8/c>
> Trace; c02e2140 <stext_lock+45b4/99d6>
> Trace; c021c10a <xfsbdstrat+3a/40>
> Trace; c01fe5b8 <xlog_bread+48/80>
> Trace; c01ff2a4 <xlog_find_zeroed+94/1e0>
> Trace; c01a553e <_pagebuf_get_object+3e/170>
> Trace; c01feb6f <xlog_find_head+1f/370>
> Trace; c01feed8 <xlog_find_tail+18/350>
> Trace; c01fc322 <xlog_alloc_log+2a2/2e0>
> Trace; c0201f40 <xlog_recover+20/c0>
> Trace; c01fb8f3 <xfs_log_mount+73/b0>
> Trace; c0202fdf <xfs_mountfs+55f/e20>
> Trace; c02026bf <xfs_readsb+af/f0>
> Trace; c01a60be <pagebuf_rele+3e/80>
> Trace; c02026eb <xfs_readsb+db/f0>
> Trace; c021e674 <kmem_alloc+e4/110>
> Trace; c020b69c <xfs_cmountfs+4bc/590>
> Trace; c020b843 <xfs_mount+63/70>
> Trace; c020b871 <xfs_vfsmount+21/40>
> Trace; c021cf48 <linvfs_read_super+188/270>
> Trace; c01294e0 <filemap_nopage+2c0/410>
> Trace; c0125f0e <handle_mm_fault+ce/e0>
> Trace; c0125d9d <do_no_page+4d/f0>
> Trace; c013cd72 <read_super+72/110>
> Trace; c013d01b <get_sb_bdev+18b/1e0>
> Trace; c013dafc <do_add_mount+1dc/290>
> Trace; c01131e0 <do_page_fault+0/4b0>
> Trace; c010724c <error_code+34/3c>
> Trace; c013dd56 <do_mount+106/120>
> Trace; c013dbfc <copy_mount_options+4c/a0>
> Trace; c013de13 <sys_mount+a3/130>
> Trace; c010715b <system_call+33/38>
> Code;  e29c0266 <[linear]linear_make_request+36/f0>
> 00000000 <_EIP>:
> Code;  e29c0266 <[linear]linear_make_request+36/f0>   <=====
>     0:   f7 f9                     idiv   %ecx,%eax   <=====
> Code;  e29c0268 <[linear]linear_make_request+38/f0>
>     2:   85 d2                     test   %edx,%edx
> Code;  e29c026a <[linear]linear_make_request+3a/f0>
>     4:   74 24                     je     2a <_EIP+0x2a> e29c0290
> <[linear]linear_make_request+60/f0>
> Code;  e29c026c <[linear]linear_make_request+3c/f0>
>     6:   55                        push   %ebp
> Code;  e29c026d <[linear]linear_make_request+3d/f0>
>     7:   51                        push   %ecx
> Code;  e29c026e <[linear]linear_make_request+3e/f0>
>     8:   68 c0 03 9c e2            push   $0xe29c03c0
> Code;  e29c0273 <[linear]linear_make_request+43/f0>
>     d:   e8 58 6c 75 dd            call   dd756c6a <_EIP+0xdd756c6a>
> c0116ed0 <printk+0/1a0>
> Code;  e29c0278 <[linear]linear_make_request+48/f0>
>    12:   6a 00                     push   $0x0
>
> Andreas Dilger wrote:
>
>  >On Aug 31, 2001  15:08 +0200, svetljo wrote:
>  >
>  >>[root@svetljo mnt]# mount -t xfs /dev/myData/Music music
>  >>Segmentation fault
>  >>
>  >
>  >Generally this is a bad sign.  Either mount is segfaulting (unlikely)
>  >or you are getting an oops in the kernel.  You need do run something
>  >like "dmesg | ksymoops" in order to get some useful data about where
>  >the problem is (could be xfs, LVM, or elsewhere in the kernel).
>  >
>  >Once you have an oops, you are best off rebooting the system, because
>  >your kernel memory may be corrupted, and cause more oopses which do
>  >not mean anything.  If you look in /var/log/messages (or 
> /var/log/kern.log
>  >or some other place, depending on where kernel messages go), you can
>  >decode the FIRST oops in the log with ksymoops.  All subsequent ones 
> are
>  >useless.
>  >
>  >
>  >>the LV ( lvcreate -i3 -I4 -L26G -nMusic )
>  >>
>  >>the VG -> myData   /dev/hdh10 /dev/linVG1/linLV1 /dev/linVG2/linLV2
>  >>
>  >>/dev/hdh10 normal partition 14G
>  >>/dev/linVG1/linLV1 ->  linear LV 14G /dev/hde6 /dev/hde12
>  >>/dev/linVg2/linLV2 ->  linear LV 14G /dev/hdg1 /dev/hdg5 /dev/hdg6
> /dev/hdg12
>  >>
>  >
>  >There is absolutely no point in doing this (not that it is possible 
> to do
>  >so anyways).  First of all, striping is almost never needed "for
> performance"
>  >unless you are normally doing very large sequential I/Os, and even 
> so most
>  >disks today have very good sequential I/O rates (e.g. 15-30MB/s).
> Secondly,
>  >you _should_ be able to just create a single LV that is striped 
> across all
>  >of the PVs above.  You would likely need to build it in steps, to 
> ensure
>  >that it is striped across the disks correctly.
>  >
>  >Cheers, Andreas
>  >
>
>
>
>
>

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

and here are the results of mkfs

###############################################################
#########   linus-2.4.9 lvm-1.0.1rc1        ###################
###############################################################

[root@svetljo root]# mkfs -t reiserfs -f /dev/myData/SRC
mkreiserfs, 2001 - reiserfsprogs 3.x.0j
===================================================================
LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey
-------------------------------------------------------------------------------
|###|type|ilen|f/sp| loc|fmt|fsck|                   key 
       |
|   |    |    |e/cn|    |   |need| 
       |
-------------------------------------------------------------------------------
Segmentation fault
[root@svetljo root]# mkfs -t ext2 -f /dev/myData/SRC
mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
mkfs.ext2: bad fragment size - /dev/myData/SRC

################################################################
###########  linux-2.4.9-ac5 lvm-1.0    ########################
################################################################

[root@svetljo root]# mkfs -t reiserfs /dev/myData/SRC
mkreiserfs, 2001 - reiserfsprogs 3.x.0j
===================================================================
LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey
-------------------------------------------------------------------------------
|###|type|ilen|f/sp| loc|fmt|fsck|                   key 
       |
|   |    |    |e/cn|    |   |need| 
       |
-------------------------------------------------------------------------------
Segmentation fault
[root@svetljo root]# mkfs -t reiserfs -f /dev/myData/SRC
mkreiserfs, 2001 - reiserfsprogs 3.x.0j
===================================================================
LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey
-------------------------------------------------------------------------------
|###|type|ilen|f/sp| loc|fmt|fsck|                   key 
       |
|   |    |    |e/cn|    |   |need| 
       |
-------------------------------------------------------------------------------
Segmentation fault
[root@svetljo root]# mkfs -t ext2 -f /dev/myData/SRC
mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
mkfs.ext2: bad fragment size - /dev/myData/SRC
[root@svetljo root]# mkfs -t ext2 /dev/myData/SRC
mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
786432 inodes, 1572864 blocks
78643 blocks (5.00%) reserved for the super user
First data block=0
48 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
         32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: Segmentation fault

#####################################################################
###    and linux-2.4.10-pre2-xfs lvm-1.0.1rc2                 #######
#####################################################################

[root@svetljo root]# mkfs -t reiserfs /dev/myData/SRC
mkreiserfs, 2001 - reiserfsprogs 3.x.0j
===================================================================
LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey
------------------------------------------------------------------------------- 
|###|type|ilen|f/sp| loc|fmt|fsck|                   key 
       | |   |    |    |e/cn|    |   |need| 
                | 
------------------------------------------------------------------------------- 
Segmentation fault
[root@svetljo root]# mkfs -t reiserfs -f /dev/myData/SRC
mkreiserfs, 2001 - reiserfsprogs 3.x.0j
===================================================================
LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey
------------------------------------------------------------------------------- 
|###|type|ilen|f/sp| loc|fmt|fsck|                   key 
       | |   |    |    |e/cn|    |   |need| 
                | 
------------------------------------------------------------------------------- 
Segmentation fault
[root@svetljo root]# mkfs -t ext2 /dev/myData/SRC
mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
786432 inodes, 1572864 blocks
78643 blocks (5.00%) reserved for the super user
First data block=0
48 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
         32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: Segmentation fault
[root@svetljo root]# mkfs -t ext2 -f /dev/myData/SRC
mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
mkfs.ext2: bad fragment size - /dev/myData/SRC
[root@svetljo root]# mkfs -t xfs /dev/myData/SRC
meta-data=/dev/myData/SRC        isize=256    agcount=8, agsize=196608 blks
data     =                       bsize=4096   blocks=1572864, imaxpct=25
          =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
[root@svetljo root]# mkfs -t xfs -f /dev/myData/SRC
meta-data=/dev/myData/SRC        isize=256    agcount=8, agsize=196608 blks
data     =                       bsize=4096   blocks=1572864, imaxpct=25
          =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

it's me again and out there is no one
so
well linux-2.4.10-pre2-xfs LVM-1.0.1rc2 works with XFS and JFS on the LV
ext2 and reiserfs segfaults as befor
i've compiled the other kernel's with JFS 1.0.4 but i don't see the
point to test them
i'm shure that JFS will work on the LV and the story with ext2 and
reiserfs will be the same
but i'll probably try the ReiserFS patches  for 2.4.9 ( after
www.namesys.com they already sent them to Linus )

i'm using e2fsprogs-1.2.4 and reiserfsprogs-3.x.0j

svetljo wrote:

 > well i did the tests
 >
 > clean Linus kernel-2.4.9  LVM-1.0.1rc1                    ext2 and
 > reiserfs segfaults
 > clean            linux-2.4.9-ac5 LVM-1.0                        ext2
 > and reiserfs segfaults
 >                   | linux-2.4.10-pre2-xfs LVM-1.0.1rc2      ext2 and
 > reiserfs segfaults, but xfs seems to work
 >                   | from SGI's cvs tree  linux-2.4-xfs taken today in
 > the early morning
 >
 > i'll try to ad IBM's JFS and try it again and i'll try bonnie on them
 > can you give me ideas how to stres the FS to find out whether it realy
 > works with XFS and JFS
 >
 > what could be wrong with ext2 and reiserfs as it works with JFS-1.0.3
 > and with the latest cvs XFS
 > svetljo wrote:
 >
 >> Hi
 >>
 >> a small adition i've tried to format the LV with ext2 and reiserfs,
 >> but it didn't worked : mkfs segfaults
 >> a strange one : i'm able to format with IBM JFS , and i can work
 >> without a problem with the LV everything just to be fine with JFS
 >>
 >> i'm currently building:
 >>  clean 2.4.9-linus with LVM-1.0.1rc1
 >>       2.4.9-ac5 with LVM-1.0 ( i couldn't do it with LVM-1.0.1rc1 & rc2)
 >>       2.4.10-pre2-xfs-cvs with LVM-1.0.1rc2
 >> to find out what is going on with ext2 reiserfs XFS ,
 >> is the problem coming from the XFS kernel changes
 >>
 >> >Hi
 >> >i'm having a serios trouble with creating
 >> >a LVM over software linear RAID
 >> >well i created it, formated it with XFS
 >> >but every time i try to mount the LV mount segfaults
 >> >and then i can not mount any other file system ( partition, CD, ..
 >> >until i reboot, when i try to mount smth mount simple stop to respond
 >> >without an error and blocks the console
 >> >
 >> >i'm using XFS cvs kernel 2.4.9 and LVM-1.0.1rc1
 >> >on ABIT's BP6 2xCelleron 533 512Mb RAM
 >> >the drives are on onboard HPT366 controler 2xWD 30Gb 1xMaxtor 40Gb
 >> >
 >> >the LV is striped over the 3 devices of the VG
 >> >the VG is /dev/hdh10 /dev/md6 /dev/md7
 >> >/dev/md6 is linear software RAID /dev/hde6 /dev/hde12
 >> >/dev/md7 is linear software RAID /dev/hdg1 /dev/hdg5 /dev/hdg6
 >> >dev/hdg11
 >> >
 >> >i posted  to the LVM-lists and there i was told
 >> >to try  "dmesg | ksymoops"
 >> >
 >> >and i became the folowing answer
 >> >
 >> > > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <=====
 >> > >
 >> > >> Trace; c023fa12 <__make_request+412/6d0>
 >> > >> Trace; c0278dcd <md_make_request+4d/80>
 >> > >> Trace; c027fa0f <lvm_make_request_fn+f/20>
 >> > >> Trace; c023fd89 <generic_make_request+b9/120>
 >> > >
 >> > >OK, so the oops is inside the RAID layer, but it may be that it is
 >> > >being fed bogus data from a higher layer.  Even so, it should not
 >> > >oops in this case.  Since XFS changes a lot of the kernel code, I
 >> > >would either suggest asking the XFS folks to look at this oops,
 >> > >or maybe on the MD RAID mailing list, as they will know more about
 >> >it.
 >> >
 >> >this is the full "dmesg | ksymoops" , i'll try to use other FS to find
 >> >out whether it's a problem with XFS, but i wish me not to have to use
 >> >other FS, i realy love XFS
 >>
 >>
 >> Using defaults from ksymoops -t elf32-i386 -a i386
 >> EFLAGS: 00010247
 >> eax: 004ac1ab   ebx: 004ac1ab   ecx: 00000000   edx: 00000000
 >> esi: d54eb320   edi: c188b928   ebp: 00958357   esp: d4eb3670
 >> ds: 0018   es: 0018   ss: 0018
 >> Process mount (pid: 5536, stackpage=d4eb3000)
 >> Stack: d54eb3e0 c023fa12 00000907 d54eb320 00000000 01c02000 c0278dcd
 >> dcec43c0
 >>         00000000 d54eb320 d54eb320 00000000 01c02000 c027fa0f 00000001
 >> d54eb320
 >>         c023fd89 c03a7254 00000000 d54eb320 00000282 00000021 00000000
 >> 00000000
 >> Call Trace: [<c023fa12>] [<c0278dcd>] [<c027fa0f>] [<c023fd89>]
 >> [<c01a6814>]
 >>     [<c01a6a85>] [<c01a6fc1>] [<c01a6c47>] [<c01a6990>] [<c0105dac>]
 >> [<c0105f1c>]
 >>     [<c02e2140>] [<c021c10a>] [<c01fe5b8>] [<c01ff2a4>] [<c01a553e>]
 >> [<c01feb6f>]
 >>     [<c01feed8>] [<c01fc322>] [<c0201f40>] [<c01fb8f3>] [<c0202fdf>]
 >> [<c02026bf>]
 >>     [<c01a60be>] [<c02026eb>] [<c021e674>] [<c020b69c>] [<c020b843>]
 >> [<c020b871>]
 >>     [<c021cf48>] [<c01294e0>] [<c0125f0e>] [<c0125d9d>] [<c013cd72>]
 >> [<c013d01b>]
 >>     [<c013dafc>] [<c01131e0>] [<c010724c>] [<c013dd56>] [<c013dbfc>]
 >> [<c013de13>]
 >>     [<c010715b>]
 >> Code: f7 f9 85 d2 74 24 55 51 68 c0 03 9c e2 e8 58 6c 75 dd 6a 00
 >>
 >>   >>EIP; e29c0266 <[linear]linear_make_request+36/f0>   <=====
 >> Trace; c023fa12 <__make_request+412/6d0>
 >> Trace; c0278dcd <md_make_request+4d/80>
 >> Trace; c027fa0f <lvm_make_request_fn+f/20>
 >> Trace; c023fd89 <generic_make_request+b9/120>
 >> Trace; c01a6814 <_pagebuf_page_io+1f4/370>
 >> Trace; c01a6a85 <_page_buf_page_apply+f5/1c0>
 >> Trace; c01a6fc1 <pagebuf_segment_apply+b1/e0>
 >> Trace; c01a6c47 <pagebuf_iorequest+f7/160>
 >> Trace; c01a6990 <_page_buf_page_apply+0/1c0>
 >> Trace; c0105dac <__down+bc/d0>
 >> Trace; c0105f1c <__down_failed+8/c>
 >> Trace; c02e2140 <stext_lock+45b4/99d6>
 >> Trace; c021c10a <xfsbdstrat+3a/40>
 >> Trace; c01fe5b8 <xlog_bread+48/80>
 >> Trace; c01ff2a4 <xlog_find_zeroed+94/1e0>
 >> Trace; c01a553e <_pagebuf_get_object+3e/170>
 >> Trace; c01feb6f <xlog_find_head+1f/370>
 >> Trace; c01feed8 <xlog_find_tail+18/350>
 >> Trace; c01fc322 <xlog_alloc_log+2a2/2e0>
 >> Trace; c0201f40 <xlog_recover+20/c0>
 >> Trace; c01fb8f3 <xfs_log_mount+73/b0>
 >> Trace; c0202fdf <xfs_mountfs+55f/e20>
 >> Trace; c02026bf <xfs_readsb+af/f0>
 >> Trace; c01a60be <pagebuf_rele+3e/80>
 >> Trace; c02026eb <xfs_readsb+db/f0>
 >> Trace; c021e674 <kmem_alloc+e4/110>
 >> Trace; c020b69c <xfs_cmountfs+4bc/590>
 >> Trace; c020b843 <xfs_mount+63/70>
 >> Trace; c020b871 <xfs_vfsmount+21/40>
 >> Trace; c021cf48 <linvfs_read_super+188/270>
 >> Trace; c01294e0 <filemap_nopage+2c0/410>
 >> Trace; c0125f0e <handle_mm_fault+ce/e0>
 >> Trace; c0125d9d <do_no_page+4d/f0>
 >> Trace; c013cd72 <read_super+72/110>
 >> Trace; c013d01b <get_sb_bdev+18b/1e0>
 >> Trace; c013dafc <do_add_mount+1dc/290>
 >> Trace; c01131e0 <do_page_fault+0/4b0>
 >> Trace; c010724c <error_code+34/3c>
 >> Trace; c013dd56 <do_mount+106/120>
 >> Trace; c013dbfc <copy_mount_options+4c/a0>
 >> Trace; c013de13 <sys_mount+a3/130>
 >> Trace; c010715b <system_call+33/38>
 >> Code;  e29c0266 <[linear]linear_make_request+36/f0>
 >> 00000000 <_EIP>:
 >> Code;  e29c0266 <[linear]linear_make_request+36/f0>   <=====
 >>     0:   f7 f9                     idiv   %ecx,%eax   <=====
 >> Code;  e29c0268 <[linear]linear_make_request+38/f0>
 >>     2:   85 d2                     test   %edx,%edx
 >> Code;  e29c026a <[linear]linear_make_request+3a/f0>
 >>     4:   74 24                     je     2a <_EIP+0x2a> e29c0290
 >> <[linear]linear_make_request+60/f0>
 >> Code;  e29c026c <[linear]linear_make_request+3c/f0>
 >>     6:   55                        push   %ebp
 >> Code;  e29c026d <[linear]linear_make_request+3d/f0>
 >>     7:   51                        push   %ecx
 >> Code;  e29c026e <[linear]linear_make_request+3e/f0>
 >>     8:   68 c0 03 9c e2            push   $0xe29c03c0
 >> Code;  e29c0273 <[linear]linear_make_request+43/f0>
 >>     d:   e8 58 6c 75 dd            call   dd756c6a <_EIP+0xdd756c6a>
 >> c0116ed0 <printk+0/1a0>
 >> Code;  e29c0278 <[linear]linear_make_request+48/f0>
 >>    12:   6a 00                     push   $0x0
 >>
 >> Andreas Dilger wrote:
 >>
 >>  >On Aug 31, 2001  15:08 +0200, svetljo wrote:
 >>  >
 >>  >>[root@svetljo mnt]# mount -t xfs /dev/myData/Music music
 >>  >>Segmentation fault
 >>  >>
 >>  >
 >>  >Generally this is a bad sign.  Either mount is segfaulting (unlikely)
 >>  >or you are getting an oops in the kernel.  You need do run something
 >>  >like "dmesg | ksymoops" in order to get some useful data about where
 >>  >the problem is (could be xfs, LVM, or elsewhere in the kernel).
 >>  >
 >>  >Once you have an oops, you are best off rebooting the system, because
 >>  >your kernel memory may be corrupted, and cause more oopses which do
 >>  >not mean anything.  If you look in /var/log/messages (or
 >> /var/log/kern.log
 >>  >or some other place, depending on where kernel messages go), you can
 >>  >decode the FIRST oops in the log with ksymoops.  All subsequent
 >> ones are
 >>  >useless.
 >>  >
 >>  >
 >>  >>the LV ( lvcreate -i3 -I4 -L26G -nMusic )
 >>  >>
 >>  >>the VG -> myData   /dev/hdh10 /dev/linVG1/linLV1 /dev/linVG2/linLV2
 >>  >>
 >>  >>/dev/hdh10 normal partition 14G
 >>  >>/dev/linVG1/linLV1 ->  linear LV 14G /dev/hde6 /dev/hde12
 >>  >>/dev/linVg2/linLV2 ->  linear LV 14G /dev/hdg1 /dev/hdg5 /dev/hdg6
 >> /dev/hdg12
 >>  >>
 >>  >
 >>  >There is absolutely no point in doing this (not that it is possible
 >> to do
 >>  >so anyways).  First of all, striping is almost never needed "for
 >> performance"
 >>  >unless you are normally doing very large sequential I/Os, and even
 >> so most
 >>  >disks today have very good sequential I/O rates (e.g. 15-30MB/s).
 >> Secondly,
 >>  >you _should_ be able to just create a single LV that is striped
 >> across all
 >>  >of the PVs above.  You would likely need to build it in steps, to
 >> ensure
 >>  >that it is striped across the disks correctly.
 >>  >
 >>  >Cheers, Andreas
 >>  >
 >>
 >>
 >>
 >>
 >>
 >
 >
 >

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

a little note
i  patch the xfs kernel but mkfs.reiserfs segfaults again

svetljo wrote:

> it's me again and out there is no one
> so
> well linux-2.4.10-pre2-xfs LVM-1.0.1rc2 works with XFS and JFS on the LV
> ext2 and reiserfs segfaults as befor
> i've compiled the other kernel's with JFS 1.0.4 but i don't see the
> point to test them
> i'm shure that JFS will work on the LV and the story with ext2 and
> reiserfs will be the same
> but i'll probably try the ReiserFS patches  for 2.4.9 ( after
> www.namesys.com they already sent them to Linus )
>
> i'm using e2fsprogs-1.2.4 and reiserfsprogs-3.x.0j
>
> svetljo wrote:
>
> > well i did the tests
> >
> > clean Linus kernel-2.4.9  LVM-1.0.1rc1                    ext2 and
> > reiserfs segfaults
> > clean            linux-2.4.9-ac5 LVM-1.0                        ext2
> > and reiserfs segfaults
> >                   | linux-2.4.10-pre2-xfs LVM-1.0.1rc2      ext2 and
> > reiserfs segfaults, but xfs seems to work
> >                   | from SGI's cvs tree  linux-2.4-xfs taken today in
> > the early morning
> >
> > i'll try to ad IBM's JFS and try it again and i'll try bonnie on them
> > can you give me ideas how to stres the FS to find out whether it realy
> > works with XFS and JFS
> >
> > what could be wrong with ext2 and reiserfs as it works with JFS-1.0.3
> > and with the latest cvs XFS
> > svetljo wrote:
> >
> >> Hi
> >>
> >> a small adition i've tried to format the LV with ext2 and reiserfs,
> >> but it didn't worked : mkfs segfaults
> >> a strange one : i'm able to format with IBM JFS , and i can work
> >> without a problem with the LV everything just to be fine with JFS
> >>
> >> i'm currently building:
> >>  clean 2.4.9-linus with LVM-1.0.1rc1
> >>       2.4.9-ac5 with LVM-1.0 ( i couldn't do it with LVM-1.0.1rc1 & 
> rc2)
> >>       2.4.10-pre2-xfs-cvs with LVM-1.0.1rc2
> >> to find out what is going on with ext2 reiserfs XFS ,
> >> is the problem coming from the XFS kernel changes
> >>
> >> >Hi
> >> >i'm having a serios trouble with creating
> >> >a LVM over software linear RAID
> >> >well i created it, formated it with XFS
> >> >but every time i try to mount the LV mount segfaults
> >> >and then i can not mount any other file system ( partition, CD, ..
> >> >until i reboot, when i try to mount smth mount simple stop to respond
> >> >without an error and blocks the console
> >> >
> >> >i'm using XFS cvs kernel 2.4.9 and LVM-1.0.1rc1
> >> >on ABIT's BP6 2xCelleron 533 512Mb RAM
> >> >the drives are on onboard HPT366 controler 2xWD 30Gb 1xMaxtor 40Gb
> >> >
> >> >the LV is striped over the 3 devices of the VG
> >> >the VG is /dev/hdh10 /dev/md6 /dev/md7
> >> >/dev/md6 is linear software RAID /dev/hde6 /dev/hde12
> >> >/dev/md7 is linear software RAID /dev/hdg1 /dev/hdg5 /dev/hdg6
> >> >dev/hdg11
> >> >
> >> >i posted  to the LVM-lists and there i was told
> >> >to try  "dmesg | ksymoops"
> >> >
> >> >and i became the folowing answer
> >> >
> >> > > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <=====
> >> > >
> >> > >> Trace; c023fa12 <__make_request+412/6d0>
> >> > >> Trace; c0278dcd <md_make_request+4d/80>
> >> > >> Trace; c027fa0f <lvm_make_request_fn+f/20>
> >> > >> Trace; c023fd89 <generic_make_request+b9/120>
> >> > >
> >> > >OK, so the oops is inside the RAID layer, but it may be that it is
> >> > >being fed bogus data from a higher layer.  Even so, it should not
> >> > >oops in this case.  Since XFS changes a lot of the kernel code, I
> >> > >would either suggest asking the XFS folks to look at this oops,
> >> > >or maybe on the MD RAID mailing list, as they will know more about
> >> >it.
> >> >
> >> >this is the full "dmesg | ksymoops" , i'll try to use other FS to 
> find
> >> >out whether it's a problem with XFS, but i wish me not to have to use
> >> >other FS, i realy love XFS
> >>
> >>
> >> Using defaults from ksymoops -t elf32-i386 -a i386
> >> EFLAGS: 00010247
> >> eax: 004ac1ab   ebx: 004ac1ab   ecx: 00000000   edx: 00000000
> >> esi: d54eb320   edi: c188b928   ebp: 00958357   esp: d4eb3670
> >> ds: 0018   es: 0018   ss: 0018
> >> Process mount (pid: 5536, stackpage=d4eb3000)
> >> Stack: d54eb3e0 c023fa12 00000907 d54eb320 00000000 01c02000 c0278dcd
> >> dcec43c0
> >>         00000000 d54eb320 d54eb320 00000000 01c02000 c027fa0f 00000001
> >> d54eb320
> >>         c023fd89 c03a7254 00000000 d54eb320 00000282 00000021 00000000
> >> 00000000
> >> Call Trace: [<c023fa12>] [<c0278dcd>] [<c027fa0f>] [<c023fd89>]
> >> [<c01a6814>]
> >>     [<c01a6a85>] [<c01a6fc1>] [<c01a6c47>] [<c01a6990>] [<c0105dac>]
> >> [<c0105f1c>]
> >>     [<c02e2140>] [<c021c10a>] [<c01fe5b8>] [<c01ff2a4>] [<c01a553e>]
> >> [<c01feb6f>]
> >>     [<c01feed8>] [<c01fc322>] [<c0201f40>] [<c01fb8f3>] [<c0202fdf>]
> >> [<c02026bf>]
> >>     [<c01a60be>] [<c02026eb>] [<c021e674>] [<c020b69c>] [<c020b843>]
> >> [<c020b871>]
> >>     [<c021cf48>] [<c01294e0>] [<c0125f0e>] [<c0125d9d>] [<c013cd72>]
> >> [<c013d01b>]
> >>     [<c013dafc>] [<c01131e0>] [<c010724c>] [<c013dd56>] [<c013dbfc>]
> >> [<c013de13>]
> >>     [<c010715b>]
> >> Code: f7 f9 85 d2 74 24 55 51 68 c0 03 9c e2 e8 58 6c 75 dd 6a 00
> >>
> >>   >>EIP; e29c0266 <[linear]linear_make_request+36/f0>   <=====
> >> Trace; c023fa12 <__make_request+412/6d0>
> >> Trace; c0278dcd <md_make_request+4d/80>
> >> Trace; c027fa0f <lvm_make_request_fn+f/20>
> >> Trace; c023fd89 <generic_make_request+b9/120>
> >> Trace; c01a6814 <_pagebuf_page_io+1f4/370>
> >> Trace; c01a6a85 <_page_buf_page_apply+f5/1c0>
> >> Trace; c01a6fc1 <pagebuf_segment_apply+b1/e0>
> >> Trace; c01a6c47 <pagebuf_iorequest+f7/160>
> >> Trace; c01a6990 <_page_buf_page_apply+0/1c0>
> >> Trace; c0105dac <__down+bc/d0>
> >> Trace; c0105f1c <__down_failed+8/c>
> >> Trace; c02e2140 <stext_lock+45b4/99d6>
> >> Trace; c021c10a <xfsbdstrat+3a/40>
> >> Trace; c01fe5b8 <xlog_bread+48/80>
> >> Trace; c01ff2a4 <xlog_find_zeroed+94/1e0>
> >> Trace; c01a553e <_pagebuf_get_object+3e/170>
> >> Trace; c01feb6f <xlog_find_head+1f/370>
> >> Trace; c01feed8 <xlog_find_tail+18/350>
> >> Trace; c01fc322 <xlog_alloc_log+2a2/2e0>
> >> Trace; c0201f40 <xlog_recover+20/c0>
> >> Trace; c01fb8f3 <xfs_log_mount+73/b0>
> >> Trace; c0202fdf <xfs_mountfs+55f/e20>
> >> Trace; c02026bf <xfs_readsb+af/f0>
> >> Trace; c01a60be <pagebuf_rele+3e/80>
> >> Trace; c02026eb <xfs_readsb+db/f0>
> >> Trace; c021e674 <kmem_alloc+e4/110>
> >> Trace; c020b69c <xfs_cmountfs+4bc/590>
> >> Trace; c020b843 <xfs_mount+63/70>
> >> Trace; c020b871 <xfs_vfsmount+21/40>
> >> Trace; c021cf48 <linvfs_read_super+188/270>
> >> Trace; c01294e0 <filemap_nopage+2c0/410>
> >> Trace; c0125f0e <handle_mm_fault+ce/e0>
> >> Trace; c0125d9d <do_no_page+4d/f0>
> >> Trace; c013cd72 <read_super+72/110>
> >> Trace; c013d01b <get_sb_bdev+18b/1e0>
> >> Trace; c013dafc <do_add_mount+1dc/290>
> >> Trace; c01131e0 <do_page_fault+0/4b0>
> >> Trace; c010724c <error_code+34/3c>
> >> Trace; c013dd56 <do_mount+106/120>
> >> Trace; c013dbfc <copy_mount_options+4c/a0>
> >> Trace; c013de13 <sys_mount+a3/130>
> >> Trace; c010715b <system_call+33/38>
> >> Code;  e29c0266 <[linear]linear_make_request+36/f0>
> >> 00000000 <_EIP>:
> >> Code;  e29c0266 <[linear]linear_make_request+36/f0>   <=====
> >>     0:   f7 f9                     idiv   %ecx,%eax   <=====
> >> Code;  e29c0268 <[linear]linear_make_request+38/f0>
> >>     2:   85 d2                     test   %edx,%edx
> >> Code;  e29c026a <[linear]linear_make_request+3a/f0>
> >>     4:   74 24                     je     2a <_EIP+0x2a> e29c0290
> >> <[linear]linear_make_request+60/f0>
> >> Code;  e29c026c <[linear]linear_make_request+3c/f0>
> >>     6:   55                        push   %ebp
> >> Code;  e29c026d <[linear]linear_make_request+3d/f0>
> >>     7:   51                        push   %ecx
> >> Code;  e29c026e <[linear]linear_make_request+3e/f0>
> >>     8:   68 c0 03 9c e2            push   $0xe29c03c0
> >> Code;  e29c0273 <[linear]linear_make_request+43/f0>
> >>     d:   e8 58 6c 75 dd            call   dd756c6a <_EIP+0xdd756c6a>
> >> c0116ed0 <printk+0/1a0>
> >> Code;  e29c0278 <[linear]linear_make_request+48/f0>
> >>    12:   6a 00                     push   $0x0
> >>
> >> Andreas Dilger wrote:
> >>
> >>  >On Aug 31, 2001  15:08 +0200, svetljo wrote:
> >>  >
> >>  >>[root@svetljo mnt]# mount -t xfs /dev/myData/Music music
> >>  >>Segmentation fault
> >>  >>
> >>  >
> >>  >Generally this is a bad sign.  Either mount is segfaulting 
> (unlikely)
> >>  >or you are getting an oops in the kernel.  You need do run something
> >>  >like "dmesg | ksymoops" in order to get some useful data about where
> >>  >the problem is (could be xfs, LVM, or elsewhere in the kernel).
> >>  >
> >>  >Once you have an oops, you are best off rebooting the system, 
> because
> >>  >your kernel memory may be corrupted, and cause more oopses which do
> >>  >not mean anything.  If you look in /var/log/messages (or
> >> /var/log/kern.log
> >>  >or some other place, depending on where kernel messages go), you can
> >>  >decode the FIRST oops in the log with ksymoops.  All subsequent
> >> ones are
> >>  >useless.
> >>  >
> >>  >
> >>  >>the LV ( lvcreate -i3 -I4 -L26G -nMusic )
> >>  >>
> >>  >>the VG -> myData   /dev/hdh10 /dev/linVG1/linLV1 /dev/linVG2/linLV2
> >>  >>
> >>  >>/dev/hdh10 normal partition 14G
> >>  >>/dev/linVG1/linLV1 ->  linear LV 14G /dev/hde6 /dev/hde12
> >>  >>/dev/linVg2/linLV2 ->  linear LV 14G /dev/hdg1 /dev/hdg5 /dev/hdg6
> >> /dev/hdg12
> >>  >>
> >>  >
> >>  >There is absolutely no point in doing this (not that it is possible
> >> to do
> >>  >so anyways).  First of all, striping is almost never needed "for
> >> performance"
> >>  >unless you are normally doing very large sequential I/Os, and even
> >> so most
> >>  >disks today have very good sequential I/O rates (e.g. 15-30MB/s).
> >> Secondly,
> >>  >you _should_ be able to just create a single LV that is striped
> >> across all
> >>  >of the PVs above.  You would likely need to build it in steps, to
> >> ensure
> >>  >that it is striped across the disks correctly.
> >>  >
> >>  >Cheers, Andreas
> >>  >
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
>
> _______________________________________________
> 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
>

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[Andreas Dilger]

On Sep 01, 2001  16:11 +0200, svetljo wrote:
> clean Linus kernel-2.4.9  LVM-1.0.1rc1                    ext2 and 
> reiserfs segfaults
> clean            linux-2.4.9-ac5 LVM-1.0                        ext2 and 
> reiserfs segfaults
>                   | linux-2.4.10-pre2-xfs LVM-1.0.1rc2      ext2 and 
> reiserfs segfaults, but xfs seems to work
>                   | from SGI's cvs tree  linux-2.4-xfs taken today in 
> the early morning

Is it possible that you are having memory problems?  Did this work with
earlier kernels and it now only fails with 2.4.9?  Have you tried running
with memtest86 to check your RAM?  It seems like you are having too many
problems with different filesystems.

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

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

wich one should i try 2.4.5 2.4.6 2.4.7 2.4.8
and should it be -ac
should i try to patch the kerenel eith badram

i'm going to run memtest now

Andreas Dilger wrote:

>On Sep 01, 2001  16:11 +0200, svetljo wrote:
>
>>clean Linus kernel-2.4.9  LVM-1.0.1rc1                    ext2 and 
>>reiserfs segfaults
>>clean            linux-2.4.9-ac5 LVM-1.0                        ext2 and 
>>reiserfs segfaults
>>                  | linux-2.4.10-pre2-xfs LVM-1.0.1rc2      ext2 and 
>>reiserfs segfaults, but xfs seems to work
>>                  | from SGI's cvs tree  linux-2.4-xfs taken today in 
>>the early morning
>>
>
>Is it possible that you are having memory problems?  Did this work with
>earlier kernels and it now only fails with 2.4.9?  Have you tried running
>with memtest86 to check your RAM?  It seems like you are having too many
>problems with different filesystems.
>
>Cheers, Andreas
>
well i'm seeing a bit different  the realy journaling FS's doesn't have 
problems
and the others not

RE: what i need is a little attention-RE [linux-lvm] SoftRaid and LVM Jean-Eric Cuendet

[Jean-Eric Cuendet]

> and one more question about the min-max
> i don't speak "C" can you tell me how to do it with pre
> linux-2.4.9patches wich i wont to aply to linux-2.4.10pre2 
> and they are giving me problems 
> with min-max definition

The min/max functions are simple functions that return the min/max of
two numbers.
Ex: min(3,4) return 3
Now, Linus has added a type to those functions in 2.4.8 (I think):
Ex: min(int, 3, 4) = 3
Or: min(float, -6.45, 4.5) = -6.45

So, either you change the call from:
min(a, b) to min(int,a,b)
Or you add the provided replacement functions:
#define min(a,b) (((a)<(b))?(a):(b)) 
#define max(a,b) (((a)>(b))?(a):(b)) 
At the *beginning* of the file (before anything else).

Note that these are not real functions but just macros. That's why it's
so simple (just add them and forget).

Bye
-jec

Re: what i need is a little attention-RE [linux-lvm] SoftRaid and LVM Jean-Eric Cuendet

[svetljo]

thanks

i think it was 2.4.9 and Alan Cox still doesn't wont it, it's quite a 
long time 2.4.9 being out there
 
 
Jean-Eric Cuendet wrote:

>>and one more question about the min-max
>>i don't speak "C" can you tell me how to do it with pre
>>linux-2.4.9patches wich i wont to aply to linux-2.4.10pre2 
>>and they are giving me problems 
>>with min-max definition
>>
>
>The min/max functions are simple functions that return the min/max of
>two numbers.
>Ex: min(3,4) return 3
>Now, Linus has added a type to those functions in 2.4.8 (I think):
>Ex: min(int, 3, 4) = 3
>Or: min(float, -6.45, 4.5) = -6.45
>
>So, either you change the call from:
>min(a, b) to min(int,a,b)
>Or you add the provided replacement functions:
>#define min(a,b) (((a)<(b))?(a):(b)) 
>#define max(a,b) (((a)>(b))?(a):(b)) 
>At the *beginning* of the file (before anything else).
>
>Note that these are not real functions but just macros. That's why it's
>so simple (just add them and forget).
>
>Bye
>-jec
>
>
>_______________________________________________
>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
>

Re: what i need is a little attention-RE [linux-lvm] SoftRaid and LVM Jean-Eric Cuendet

[svetljo]

some ideas whom should i write to and what else should i try
i've already written to the developers of e2fsprogs and to Hans Reiser
but i still don't have a reply( it was 2-3 days ago) and mr Hans Reiser 
wonts $25 for looking at a problem
i'll write them again



Jean-Eric Cuendet wrote:

>>and one more question about the min-max
>>i don't speak "C" can you tell me how to do it with pre
>>linux-2.4.9patches wich i wont to aply to linux-2.4.10pre2 
>>and they are giving me problems 
>>with min-max definition
>>
>
>The min/max functions are simple functions that return the min/max of
>two numbers.
>Ex: min(3,4) return 3
>Now, Linus has added a type to those functions in 2.4.8 (I think):
>Ex: min(int, 3, 4) = 3
>Or: min(float, -6.45, 4.5) = -6.45
>
>So, either you change the call from:
>min(a, b) to min(int,a,b)
>Or you add the provided replacement functions:
>#define min(a,b) (((a)<(b))?(a):(b)) 
>#define max(a,b) (((a)>(b))?(a):(b)) 
>At the *beginning* of the file (before anything else).
>
>Note that these are not real functions but just macros. That's why it's
>so simple (just add them and forget).
>
>Bye
>-jec
>
>
>_______________________________________________
>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
>

Re: what i need is a little attention-RE [linux-lvm] SoftRaid and LVM Jean-Eric Cuendet

[Andreas Dilger]

On Sep 05, 2001  10:33 +0200, svetljo wrote:
> some ideas whom should i write to and what else should i try
> i've already written to the developers of e2fsprogs and to Hans Reiser
> but i still don't have a reply( it was 2-3 days ago) and mr Hans Reiser 
> wonts $25 for looking at a problem

I don't think it has anything to do with e2fsprogs or reiserfs.  The
problem is clearly in LVM, MD, or the block layer.  Thousands of people
are using both e2fsprogs and reiserfsprogs, and if they had such problems
more people would know about it.

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

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

and what should i try now
i was writing to Nail Brown about the XFS mount problem  but i think he 
stop writing to me
after i couldn't recreate the problem

which kernel should i test 2.4.5 2.4.6 2.4.7

Andreas Dilger wrote:

>On Sep 05, 2001  10:33 +0200, svetljo wrote:
>
>>some ideas whom should i write to and what else should i try
>>i've already written to the developers of e2fsprogs and to Hans Reiser
>>but i still don't have a reply( it was 2-3 days ago) and mr Hans Reiser 
>>wonts $25 for looking at a problem
>>
>
>I don't think it has anything to do with e2fsprogs or reiserfs.  The
>problem is clearly in LVM, MD, or the block layer.  Thousands of people
>are using both e2fsprogs and reiserfsprogs, and if they had such problems
>more people would know about it.
>
>Cheers, Andreas
>

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

i'm building curently 2.4.10-pre4-xfs with the patches from Neil Brown
and i'll try with a Mandrake-2.4.5 i'll have to update the LVM-code of 
the is it necessary to be lvm-1.0.1rc2
or i can do it with lvm-1.0 for the mandrake kernel (my internet 
connection pretty slow currently)  

svetljo wrote:

> and what should i try now
> i was writing to Nail Brown about the XFS mount problem  but i think 
> he stop writing to me
> after i couldn't recreate the problem
>
> which kernel should i test 2.4.5 2.4.6 2.4.7
>
> Andreas Dilger wrote:
>
>> On Sep 05, 2001  10:33 +0200, svetljo wrote:
>>
>>> some ideas whom should i write to and what else should i try
>>> i've already written to the developers of e2fsprogs and to Hans Reiser
>>> but i still don't have a reply( it was 2-3 days ago) and mr Hans 
>>> Reiser wonts $25 for looking at a problem
>>>
>>
>> I don't think it has anything to do with e2fsprogs or reiserfs.  The
>> problem is clearly in LVM, MD, or the block layer.  Thousands of people
>> are using both e2fsprogs and reiserfsprogs, and if they had such 
>> problems
>> more people would know about it.
>>
>> Cheers, Andreas
>>
>
>
>
> _______________________________________________
> 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
>

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[Andreas Dilger]

On Sep 05, 2001  20:18 +0200, svetljo wrote:
> i was writing to Nail Brown about the XFS mount problem  but i think he 
> stop writing to me after i couldn't recreate the problem
> 
> which kernel should i test 2.4.5 2.4.6 2.4.7

If you had one that previously worked, then start with that one and
work forwards until it stops working (maybe dividing the kernel version
numbers in half for each try to narrow it down quicker).

If you have never had this working properly, try some early kernel like
2.4.5 and see if it works.  If not then I suspect you have a RAM problem,
and you may want to swap/remove SIMM/DIMMs to see if you can isolate it.

There is a whole document in linux/Documentation/, like Oops-tracing.txt,
BUG-HUNTING, etc.

Nobody HAS to help you with this problem (and it seems the Sistina
folks are quiet on this issue) because you are not paying them anything.
That is one of the good/bad features of Linux - you can _usually_ get
free support for a problem, but you may have to do it yourself too.

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

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

i can not understand one thing

Andreas Dilger wrote:

>If you had one that previously worked, then start with that one and
>work forwards until it stops working (maybe dividing the kernel version
>numbers in half for each try to narrow it down quicker).
>
i maked the VG and the LV's under 2.4.9-xfs lvm-1.0.1rc1
but i had the XFS- mount problem with it and JFS had no problems
and i upgraded to 2.4.10-pre2-xfs lvm-1.0.1rc2 and had no problems with 
JFS and XFS
i tried with 2.4.9-ac5 lvm-1.0 and vanila 2.4.9 lvm-1.0.1rc1
with all these kernels it seemd that the LVM is working but i couldn't 
format the LV with reiserfs and ext2
mke2fs and mkreiserfs simply segfaults without errors

>If you have never had this working properly, try some early kernel like
>2.4.5 and see if it works.  If not then I suspect you have a RAM problem,
>and you may want to swap/remove SIMM/DIMMs to see if you can isolate it.
>
i can not understand why do you think that i could have RAM problems
if i had RAM problems why would XFS and JFS working without problem and
mke2fs and mkreiserfs segfaulting

>
>There is a whole document in linux/Documentation/, like Oops-tracing.txt,
>BUG-HUNTING, etc.
>
i'll take a look at it

>
>Nobody HAS to help you with this problem (and it seems the Sistina
>folks are quiet on this issue) because you are not paying them anything.
>That is one of the good/bad features of Linux - you can _usually_ get
>free support for a problem, but you may have to do it yourself too.
>
>Cheers, Andreas
>
i know that and i really appreciate that you are trying to help me

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[Andreas Dilger]

On Sep 05, 2001  20:57 +0200, svetljo wrote:
> i maked the VG and the LV's under 2.4.9-xfs lvm-1.0.1rc1
> but i had the XFS- mount problem with it and JFS had no problems
> and i upgraded to 2.4.10-pre2-xfs lvm-1.0.1rc2 and had no problems with 
> JFS and XFS

When you say you have no problems, does that mean "mkfs.{jfs,xfs} completed
without errors" or does that mean "I have been using {JFS,XFS} under load
or running dbench/bonnie++ on it without errors".  Since you say that
memtest86 does not show errors on your system, you could also try dbench,
bonnie++, or even cerberus (from VA Linux) to stress test these filesystems.
I'm pretty sure they will also show problems under stress, and this will
convince you it is a kernel or hardware problem.

> i tried with 2.4.9-ac5 lvm-1.0 and vanila 2.4.9 lvm-1.0.1rc1
> with all these kernels it seemd that the LVM is working but i couldn't 
> format the LV with reiserfs and ext2
> mke2fs and mkreiserfs simply segfaults without errors

The fact that mkfs.* is causing a kernel OOPS is a sure sign of problems
in the kernel, because these are just user-space applications, and do
not run in the kernel at all.  I don't think it could possibly be a
problem with these tools.

> >If you have never had this working properly, try some early kernel like
> >2.4.5 and see if it works.  If not then I suspect you have a RAM problem,
> >and you may want to swap/remove SIMM/DIMMs to see if you can isolate it.
> >
> i can not understand why do you think that i could have RAM problems
> if i had RAM problems why would XFS and JFS working without problem and
> mke2fs and mkreiserfs segfaulting

There have been problems with mke2fs in the past (and maybe mkreiserfs too)
where they make a LOT of blocks dirty which exposes problems in the block
I/O layer inside the kernel.  This does not mean that these tools are bad,
it means the kernel is bad, or your system is bad, and these are tools
that show this problem best.

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

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[svetljo]

Andreas Dilger wrote:

>On Sep 05, 2001  20:57 +0200, svetljo wrote:
>
>>i maked the VG and the LV's under 2.4.9-xfs lvm-1.0.1rc1
>>but i had the XFS- mount problem with it and JFS had no problems
>>and i upgraded to 2.4.10-pre2-xfs lvm-1.0.1rc2 and had no problems with 
>>JFS and XFS
>>
>
>When you say you have no problems, does that mean "mkfs.{jfs,xfs} completed
>without errors" or does that mean "I have been using {JFS,XFS} under load
>or running dbench/bonnie++ on it without errors".  Since you say that
>memtest86 does not show errors on your system, you could also try dbench,
>bonnie++, or even cerberus (from VA Linux) to stress test these filesystems.
>I'm pretty sure they will also show problems under stress, and this will
>convince you it is a kernel or hardware problem.
>
well i already downloaded dbench and bonnie++ and i'll try to find cerberus
but i had downloaded vanila 2.4.7 at 2.3k/s so it took me some time and 
i was thinking to try to boot with / on the  LV
and i had to make some backups

>>i tried with 2.4.9-ac5 lvm-1.0 and vanila 2.4.9 lvm-1.0.1rc1
>>with all these kernels it seemd that the LVM is working but i couldn't 
>>format the LV with reiserfs and ext2
>>mke2fs and mkreiserfs simply segfaults without errors
>>
>
>The fact that mkfs.* is causing a kernel OOPS is a sure sign of problems
>in the kernel, because these are just user-space applications, and do
>not run in the kernel at all.  I don't think it could possibly be a
>problem with these tools.
>
i couldn't find any OOPS 's after running mkreiserfs and mke2fs

>>>If you have never had this working properly, try some early kernel like
>>>2.4.5 and see if it works.  If not then I suspect you have a RAM problem,
>>>and you may want to swap/remove SIMM/DIMMs to see if you can isolate it.
>>>
>>i can not understand why do you think that i could have RAM problems
>>if i had RAM problems why would XFS and JFS working without problem and
>>mke2fs and mkreiserfs segfaulting
>>
>
>There have been problems with mke2fs in the past (and maybe mkreiserfs too)
>where they make a LOT of blocks dirty which exposes problems in the block
>I/O layer inside the kernel.  This does not mean that these tools are bad,
>it means the kernel is bad, or your system is bad, and these are tools
>that show this problem best.
>
>Cheers, Andreas
>
thanks a lot

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)

[Luca Berra]

On Wed, Sep 05, 2001 at 08:57:02PM +0200, svetljo wrote:
> Andreas Dilger wrote:
> >If you had one that previously worked, then start with that one and
> >work forwards until it stops working (maybe dividing the kernel version
> >numbers in half for each try to narrow it down quicker).
...
> i tried with 2.4.9-ac5 lvm-1.0 and vanila 2.4.9 lvm-1.0.1rc1
> with all these kernels it seemd that the LVM is working but i couldn't 
> format the LV with reiserfs and ext2

i have an older kernel 2.4.4-ac11 and it works beautifully.
i will try to upgrade this weekend and will let you know.
besides 2.4.9-ac does not even boot on my hardware.

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)-2.4.7

[svetljo]

Hi again
it took me some time but it's the same with 2.4.7
mke2fs and mkreiserfs segfaults and there are no OOPSes
and jfs has no problems

vanila 2.4.7 with jfs-1.0.4 and LVM-cvs from about an hour ago 

RE: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?)-2.4.7

[Jonathan DeHaan]

svetljo,
I think I've done what you are trying to do.

Starting with Mandrake 8.1b1:
kernel 2.4.9
patch-2.4.9-xfs-2001-08-26
lvm-1.0.1-rc2
xfsprogs-1.3.5
Apply xfs patch before doing make in lvm.
Configure lvmtools with --enable-static_link

/dev/md/0 is RAID0 over three partitions - hda1, sda1, sdb1
pvcreate /dev/md/0
vgcreate vg /dev/md/0
lvcreate -s 4G -n root vg
mkfs -t xfs /dev/vg/root
mount /dev/vg/root /mnt

No errors.

If this same sequence of commands produces errors on your system, then I
would suspect something other than md, lvm, or xfs. Unless you really have a
need to run both, I would not patch both XFS and JFS into the same kernel. I
also would not use modules for any filesystems that I expect to use daily.

Hope this helps,
Jonathan DeHaan
jdehaan@home.com

> -----Original Message-----
> From: linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com]On
> Behalf Of svetljo
> Sent: Thursday, September 06, 2001 1:28 PM
> To: linux-lvm@sistina.com
> Subject: Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ?
> ext2 reiserfs?)-2.4.7
>
>
> Hi again
> it took me some time but it's the same with 2.4.7
> mke2fs and mkreiserfs segfaults and there are no OOPSes
> and jfs has no problems
>
> vanila 2.4.7 with jfs-1.0.4 and LVM-cvs from about an hour ago
>
>
> _______________________________________________
> 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
>