[linux-lvm] Re: HELP changing md-device's partition-type to LVM

[linux-lvm] Re: HELP changing md-device's partition-type to LVM

[svetljo]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Hi i couldn't change the partition's id of the RAID but i mannaged it to 
create the VG, LV and to format the LV
but when i try to mount the the LV mount segfaults  and every try to do 
anything with the LV finish witth a sleep
i mean when i try to mount anything ( a partition, a CD or a LV) after 
the segfault of the first ' mount -t xfs /dev/myData/Music /mnt/music ' 
 mount goes to sleep and do not do anything
vgdisplay says that the volume is activ
lvremove says that the volume is open and can not be removed 
do you have an idea wthat is the problem
and what can i try

the LV ( lvcreate -i3 -I4 -L26G -nMusic )

the VG -> myData   /dev/hdh10 /dev/md6 /dev/md7

/dev/hdh10 normal partition 14G
/dev/md6 ->  linear software RAID 14G /dev/hde6 /dev/hde12
/dev/md7 ->  linear software RAID 14G /dev/hdg1 /dev/hdg5 /dev/hdg6 
/dev/hdg12

the reason:

after trying BeOS, FreeBSD and useing windows , i was trying to switch 
complete to linux without having to repartiton all the drives( i have tree )
and lose about 30G of Data + and a new instalation ( the current Data 
and instalation is over a software RAID-0 other a striped  LV's  or to 
back up 30 Gigs of Data
AJ Lewis wrote:

>On Thu, Aug 30, 2001 at 03:26:38PM +0200, svetljo wrote:
>
>>Hi i saw your postings on the lvm-board
>>and i was woundering whether you can help me
>>
>>can you plese tell me how can i change the type  of  'partition' on 
>>md-device (softweare Linear RAID )
>>i can not make it with fdisk on md-device
>>
>>i have 3 disks with a lot of partitions and i wanted to build  striped 
>>LV's on a new VG
>>i've created the VG ( /dev/md5 /dev/md6 /dev/hdh10 )
>>but when i try to create LV's  it returns to me that not all PV's are 
>>online ( md5 )
>>and /proc/mdstat tells me that everything is ok :
>> md5 ( /dev/hde6 /dev/hde12 linear) and md6 (/dev/hdg1 /dev/hdg2 
>>/dev/hdg8 linear) are online
>>but they are marked as ext2 partitions
>>
>>can you please help me
>>
>
>I'm sorry.  I don't personally have any experience using md.  I suggest you
>post this to linux-lvm.  There should be people there that have done what
>you're proposing.
>
>>linux-2.4.9-xfs-cvs  with LVM 1.0.1rc1
>>
>
>Regards,
>



[-- Attachment #2: Type: text/html, Size: 2746 bytes --]

[linux-lvm] Re: HELP changing md-device's partition-type to LVM(or may be LV's partition id)

[svetljo]

i have forgoten my mail : svetljo@lycos.com 
 galia@st-peter.stw.uni-erlangen.de
i'll be tankfull for any idea  write me

and one more question :

can i make a VG and LV's over  LV's
the idea is replacing the linear sofware RAID with a linear LV's, but i 
think i'll have the same roblems that i had with the raid

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


> Hi i couldn't change the partition's id of the RAID but i mannaged it 
> to create the VG, LV and to format the LV
> but when i try to mount the the LV mount segfaults  and every try to 
> do anything with the LV finish witth a sleep
> i mean when i try to mount anything ( a partition, a CD or a LV) after 
> the segfault of the first ' mount -t xfs /dev/myData/Music /mnt/music 
> '  mount goes to sleep and do not do anything
> vgdisplay says that the volume is activ
> lvremove says that the volume is open and can not be removed 
> do you have an idea wthat is the problem
> and what can i try
>
> the LV ( lvcreate -i3 -I4 -L26G -nMusic )
>
> the VG -> myData   /dev/hdh10 /dev/md6 /dev/md7
>
> /dev/hdh10 normal partition 14G
> /dev/md6 ->  linear software RAID 14G /dev/hde6 /dev/hde12
> /dev/md7 ->  linear software RAID 14G /dev/hdg1 /dev/hdg5 /dev/hdg6 
> /dev/hdg12
>
> the reason:
>
> after trying BeOS, FreeBSD and useing windows , i was trying to switch 
> complete to linux without having to repartiton all the drives( i have 
> tree )
> and lose about 30G of Data + and a new instalation ( the current Data 
> and instalation is over a software RAID-0 other a striped  LV's  or to 
> back up 30 Gigs of Data
> AJ Lewis wrote:
>
>>On Thu, Aug 30, 2001 at 03:26:38PM +0200, svetljo wrote:
>>
>>>Hi i saw your postings on the lvm-board
>>>and i was woundering whether you can help me
>>>
>>>can you plese tell me how can i change the type  of  'partition' on 
>>>md-device (softweare Linear RAID )
>>>i can not make it with fdisk on md-device
>>>
>>>i have 3 disks with a lot of partitions and i wanted to build  striped 
>>>LV's on a new VG
>>>i've created the VG ( /dev/md5 /dev/md6 /dev/hdh10 )
>>>but when i try to create LV's  it returns to me that not all PV's are 
>>>online ( md5 )
>>>and /proc/mdstat tells me that everything is ok :
>>> md5 ( /dev/hde6 /dev/hde12 linear) and md6 (/dev/hdg1 /dev/hdg2 
>>>/dev/hdg8 linear) are online
>>>but they are marked as ext2 partitions
>>>
>>>can you please help me
>>>
>>
>>I'm sorry.  I don't personally have any experience using md.  I suggest you
>>post this to linux-lvm.  There should be people there that have done what
>>you're proposing.
>>
>>>linux-2.4.9-xfs-cvs  with LVM 1.0.1rc1
>>>
>>
>>Regards,
>>
>
>

[linux-lvm] PBs with LVM over software RAID

[svetljo]

i have forgoten my mail : svetljo@lycos.com
  galia@st-peter.stw.uni-erlangen.de
i'll be tankfull for any idea  write me


can somebody tell me where is the problem and what can i do about it
the first time i try to mount the LV mount segfaults and after that i am 
not able to mount any other file system ( partition, CD ...) :

root@svetljo#mount -o ro /dev/scd0 /mnt/cdrom
no messeges from mount but it blocks the console and does not mount the CD



i'm running MDK8.1(cooker) with kernel 2.4.9-xfs-cvs with LVM 1.0.1-rc1
ABIT BP6 dual Celleron533 512Mb RAM
onboard HPT366 UDMA66 controler
on the HPT366  2xWD 30Gb(/dev/hde /dev/hdg) 1xMaxtor 40Gb(/dev/hdh)

here is the console output:

[root@svetljo mnt]# cat /proc/mdstat
Personalities : [linear] [raid0] [raid5]
read_ahead 1024 sectors
md7 : active linear hde6[1] hde11[0]       13936128 blocks 64k rounding
md6 : active linear hdg6[3] hdg12[2] hdg1[1] hdg5[0]       14409856 
blocks 64k rounding
md0 : active raid0 hdh6[2] hdg10[1] hde8[0]       8064256 blocks 8k chunks
md1 : active raid0 hdh7[2] hdg9[1] hde10[0]       24579072 blocks 16k 
chunks
md8 : active raid0 hdh8[1] hdg7[0]       529920 blocks 64k chunks
unused devices: <none>
[root@svetljo mnt]# vgscan
  vgscan -- reading all physical volumes (this may take a while...)
  vgscan -- found active volume group "myData"
  vgscan -- found active volume group "wish"
  vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
  vgscan -- WARNING: This program does not do a VGDA backup of your 
volume groups
[root@svetljo mnt]# vgdisplay myData
--- Volume group ---
VG Name               myData
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                255
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                255
Cur PV                3
Act PV                3
VG Size               41.50 GB
PE Size               4.00 MB
Total PE              10624
Alloc PE / Size       7170 / 28.01 GB
Free  PE / Size       3454 / 13.49 GB
VG UUID               EqfM1F-WKiN-41Jw-D7kl-PSwv-jLp7-4fFjIo

[root@svetljo mnt]# lvdisplay /dev/myData/Music
--- Logical volume ---
LV Name                /dev/myData/Music
VG Name                myData
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                28.01 GB
Current LE             7170
Allocated LE           7170
Stripes                3
Stripe size (KByte)    4
Allocation             next free
Read ahead sectors     32
Block device           58:0
[root@svetljo mnt]# mount -t xfs /dev/myData/Music music
Segmentation fault
[root@svetljo mnt]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/md0               8064004   7593920    470084  95% /
/dev/hde5                31079     23564      5911  80% /boot
none                    256252         0    256252   0% /dev/shm
/dev/md1              24574272  24444608    129664 100% /mnt/md1
/dev/hde1               441520    272376    169144  62% /mnt/win_c
[root@svetljo mnt]# lvdisplay /dev/myData/Music
--- Logical volume ---
LV Name                /dev/myData/Music
VG Name                myData
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 1             <----
LV Size                28.01 GB
Current LE             7170
Allocated LE           7170
Stripes                3
Stripe size (KByte)    4
Allocation             next free
Read ahead sectors     32
Block device           58:0


------------------------------------------------------------------------

and one more question :

can i make a VG and LV's over  LV's
the idea is replacing the linear sofware RAID with a linear LV's, but i
think i'll have the same roblems that i had with the raid

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


 > Hi i couldn't change the partition's id of the RAID but i mannaged it
 > to create the VG, LV and to format the LV
 > but when i try to mount the the LV mount segfaults  and every try to
 > do anything with the LV finish witth a sleep
 > i mean when i try to mount anything ( a partition, a CD or a LV) after
 > the segfault of the first ' mount -t xfs /dev/myData/Music /mnt/music
 > '  mount goes to sleep and do not do anything
 > vgdisplay says that the volume is activ
 > lvremove says that the volume is open and can not be removed
 > do you have an idea wthat is the problem
 > and what can i try
 >
 > the LV ( lvcreate -i3 -I4 -L26G -nMusic )
 >
 > the VG -> myData   /dev/hdh10 /dev/md6 /dev/md7
 >
 > /dev/hdh10 normal partition 14G
 > /dev/md6 ->  linear software RAID 14G /dev/hde6 /dev/hde12
 > /dev/md7 ->  linear software RAID 14G /dev/hdg1 /dev/hdg5 /dev/hdg6
 > /dev/hdg12
 >
 > the reason:
 >
 > after trying BeOS, FreeBSD and useing windows , i was trying to switch
 > complete to linux without having to repartiton all the drives( i have
 > tree )
 > and lose about 30G of Data + and a new instalation ( the current Data
 > and instalation is over a software RAID-0 other a striped  LV's  or to
 > back up 30 Gigs of Data
 > AJ Lewis wrote:
 >
 >>On Thu, Aug 30, 2001 at 03:26:38PM +0200, svetljo wrote:
 >>
 >>>Hi i saw your postings on the lvm-board
 >>>and i was woundering whether you can help me
 >>>
 >>>can you plese tell me how can i change the type  of  'partition' on
 >>>md-device (softweare Linear RAID )
 >>>i can not make it with fdisk on md-device
 >>>
 >>>i have 3 disks with a lot of partitions and i wanted to build  striped
 >>>LV's on a new VG
 >>>i've created the VG ( /dev/md5 /dev/md6 /dev/hdh10 )
 >>>but when i try to create LV's  it returns to me that not all PV's are
 >>>online ( md5 )
 >>>and /proc/mdstat tells me that everything is ok :
 >>> md5 ( /dev/hde6 /dev/hde12 linear) and md6 (/dev/hdg1 /dev/hdg2
 >>>/dev/hdg8 linear) are online
 >>>but they are marked as ext2 partitions
 >>>
 >>>can you please help me
 >>>
 >>
 >>I'm sorry.  I don't personally have any experience using md.  I 
suggest you
 >>post this to linux-lvm.  There should be people there that have done what
 >>you're proposing.
 >>
 >>>linux-2.4.9-xfs-cvs  with LVM 1.0.1rc1
 >>>
 >>
 >>Regards,
 >>
 >
 >

Re: [linux-lvm] Re: HELP changing md-device's partition-type to LVM(or may be LV's partition id)

[Lewis Bergman]

I had a hard time following this thread but it sounds similiar to what I am 
doing.
I have 2 SCSI disks on an AIC7899 controller channel's A and B. They are 
partioned like so.
   Device Boot    Start       End    Blocks   Id  System
/dev/sda1   *         1         8     64228+  fd  Linux raid autodetect
/dev/sda2             9       136   1028160   fd  Linux raid autodetect
/dev/sda3           137       201    522112+  fd  Linux raid autodetect
/dev/sda4           202      2247  16434495   fd  Linux raid autodetect

   Device Boot    Start       End    Blocks   Id  System
/dev/sdb1   *         1         8     64228+  fd  Linux raid autodetect
/dev/sdb2             9       136   1028160   fd  Linux raid autodetect
/dev/sdb3           137       201    522112+  fd  Linux raid autodetect
/dev/sdb4           202      2247  16434495   fd  Linux raid autodetect

The md's look like this:
[root@portal /etc]# cat raidtab
raiddev             /dev/md0
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
#nr-spare-disks     0
    device          /dev/sda1
    raid-disk     0
    device          /dev/sdb1
    raid-disk     1
raiddev             /dev/md1
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
#nr-spare-disks     0
    device          /dev/sda2
    raid-disk     0
    device          /dev/sdb2
    raid-disk     1
raiddev             /dev/md2
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
#nr-spare-disks     0
    device          /dev/sda3
    raid-disk     0
    device          /dev/sdb3
    raid-disk     1
raiddev             /dev/md3
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
#nr-spare-disks     0
    device          /dev/sda4
    raid-disk     0
    device          /dev/sdb4
    raid-disk     1

On top of these I built some ext2, and LVM's on which I placed reiserfs's.
Finally, the lvm stuff look like this:
[root@portal /etc]# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/md3" of VG "mainlvm" [15.67 GB / 4.18 GB free]
pvscan -- total: 1 [15.67 GB] / in use: 1 [15.67 GB] / in no VG: 0 [0]
 
[root@portal /etc]# vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "mainlvm"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume group
 
[root@portal /etc]# lvscan
lvscan -- ACTIVE            "/dev/mainlvm/home" [500.00 MB]
lvscan -- ACTIVE            "/dev/mainlvm/usr" [3.00 GB]
lvscan -- ACTIVE            "/dev/mainlvm/usrlocal" [5.00 GB]
lvscan -- ACTIVE            "/dev/mainlvm/var" [3.00 GB]
lvscan -- 4 logical volumes with 11.49 GB total in 1 volume group
lvscan -- 4 active logical volumes

I have no idea if this is the right way to do it or not. I get no segfaults 
and have not noticed any fs corruption. I think software raid pretty much 
stinks but sometimes you have to go with what you have, not what you wished 
you had.

Sorry if this was a waste of your time.
-- 
Lewis Bergman
Texas Communications
4309 Maple St.
Abilene, TX 79602-8044
915-695-6962

[linux-lvm] Re: HELP changing md-device's partition-type to LVM

[svetljo]

well could it be then some problem with linear RAID

i had it working over software RAID-0 some time ago with LVM-0.9.1beta2 
i think

or some kernel issue

Re: [linux-lvm] PBs with LVM over software RAID

[Andreas Dilger]

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

[svetljo]

hey that's it and what now
do you think that i have to try with another kernel or FS
for me xfs is the best

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

[Andreas Dilger]

On Aug 31, 2001  20:37 +0200, svetljo wrote:
> 
> >>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.

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

[svetljo]

do you think i schould also try a kernel upgrade and/or LVm
the XFS cvs tree should be till 2.4.10pre2 and sistina released lvm-1.0.1rc2
and i'm with XFS cvs kernel-2.4.9 and lvm-1.0.1rc1 
Andreas Dilger wrote:

>On Aug 31, 2001  20:37 +0200, svetljo wrote:
>
>>>>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.
>
>Cheers, Andreas
>

Re: [linux-lvm] PBs with LVM over software RAID

[svetljo]

hi
it works with IMB's JFS
when i try mkfs -t reiserfs -f /dev/myData/SRC it segfaults :

[root@svetljo mnt]# 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

isn't that a bit strange that reiserfs and xfs doesn't handle it, but 
jfs does

and the one with ext2 :

[root@svetljo mnt]# 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

i realy don't like that

Andreas Dilger wrote:

>On Aug 31, 2001  20:37 +0200, svetljo wrote:
>
>>>>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.
>
>Cheers, Andreas
>

Re: [linux-lvm] PBs with LVM over software RAID

[svetljo]

hi
it works with IMB's JFS
when i try mkfs -t reiserfs -f /dev/myData/SRC it segfaults :

[root@svetljo mnt]# 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

isn't that a bit strange that reiserfs and xfs doesn't handle it, but
jfs does

and the one with ext2 :

[root@svetljo mnt]# 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

i realy don't like that

Andreas Dilger wrote:

 >On Aug 31, 2001  20:37 +0200, svetljo wrote:
 >
 >>>>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.
 >
 >Cheers, Andreas
 >

Re: [linux-lvm] PBs with LVM over software RAID

[Andreas Dilger]

On Sep 01, 2001  00:24 +0200, svetljo wrote:
> it works with IMB's JFS
> when i try mkfs -t reiserfs -f /dev/myData/SRC it segfaults :
> 
> [root@svetljo mnt]# 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
> 
> isn't that a bit strange that reiserfs and xfs doesn't handle it, but 
> jfs does

It could just be lucky that JFS works, depending on access patterns.

> and the one with ext2 :
> 
> [root@svetljo mnt]# 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

Then it is definitely not anything to do with the filesystem itself
(although it may be with the XFS patch).  Try a kernel without the
XFS patch and see if this makes a difference.  Maybe it is a bad
interaction between XFS, RAID, LVM?

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

[svetljo]

i'll try with 2.4.9 and with 2.4.9ac5
how do you think should i do it with LVM-1.0.1rc1 or rc2
i think i should try with rc1 to find whether it comes from the xfs 
kernel changes, as i'm currently using rc1

Andreas Dilger wrote:

>On Sep 01, 2001  00:24 +0200, svetljo wrote:
>
>>it works with IMB's JFS
>>when i try mkfs -t reiserfs -f /dev/myData/SRC it segfaults :
>>
>>[root@svetljo mnt]# 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
>>
>>isn't that a bit strange that reiserfs and xfs doesn't handle it, but 
>>jfs does
>>
>
>It could just be lucky that JFS works, depending on access patterns.
>
>>and the one with ext2 :
>>
>>[root@svetljo mnt]# 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
>>
>
>Then it is definitely not anything to do with the filesystem itself
>(although it may be with the XFS patch).  Try a kernel without the
>XFS patch and see if this makes a difference.  Maybe it is a bad
>interaction between XFS, RAID, LVM?
>
>Cheers, Andreas
>

[linux-lvm] PBs with -ac kernels and LVM 1.0.1 rc1 and rc2

[svetljo]

hi i've tried to compile linux-2.4.9-ac5 with LVM-1.0.1rc1 and rc2 ,but 
i couldn't do it, but it work with LVM-1.0

i think it's the 'min - max ' problem and that Alan doesn't like it

have anyone compiled succesfully  2.4.9-acX with LVM-1.0.1rc1 or rc2

i'll post later the error

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: [linux-lvm] PBs with LVM over software RAID

[Olivier Sessink]

On  0, svetljo <galia@st-peter.stw.uni-erlangen.de> wrote:
> hi
> it works with IMB's JFS
> when i try mkfs -t reiserfs -f /dev/myData/SRC it segfaults :
> 
> [root@svetljo mnt]# 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
> 
> isn't that a bit strange that reiserfs and xfs doesn't handle it, but 
> jfs does

reiserfs is known to stress hardware more, a lot of people with
almost-stable hardware get problems when using reiserfs. XFS might behave
the same. Test your system using memtest86, and run 'make -j3 clean bzImage'
in a loop for a while to check if your hardware is OK.

regards,
	Olivier
-- 
begin signature_virus.TXT.vbs
Hi, I'm a signature virus. plz set me as your signature and help me
spread :)
end

Re: [linux-lvm] PBs with LVM over software RAID

[svetljo]

i'll do the loop and i already did the memtest86 i had no probs
and what about mke2fs it also segfaults
and when it stresses the hardware why didn't it crashed the system and 
only segfaults without errors ?

Olivier Sessink wrote:

>On  0, svetljo <galia@st-peter.stw.uni-erlangen.de> wrote:
>
>>hi
>>it works with IMB's JFS
>>when i try mkfs -t reiserfs -f /dev/myData/SRC it segfaults :
>>
>>[root@svetljo mnt]# 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
>>
>>isn't that a bit strange that reiserfs and xfs doesn't handle it, but 
>>jfs does
>>
>
>reiserfs is known to stress hardware more, a lot of people with
>almost-stable hardware get problems when using reiserfs. XFS might behave
>the same. Test your system using memtest86, and run 'make -j3 clean bzImage'
>in a loop for a while to check if your hardware is OK.
>
>regards,
>	Olivier
>