[linux-lvm] Trouble running LVM under Redhat 7.2?
Aslak Sommerfelt Skretting
aslak at skretting.org
Thu Feb 28 05:20:02 UTC 2002
Hello everyone.
Does anyone know of any problems that might occur when running LVM under
Redhat 7.2?
This is my lvm setup, on two 120gb disks and two 100gb disks.
root at space.uNF.no:/space# vgdisplay -v storage
--- Volume group ---
VG Name storage
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 255
Cur LV 1
Open LV 1
MAX LV Size 2 TB
Max PV 255
Cur PV 4
Act PV 4
VG Size 406.41 GB
PE Size 32 MB
Total PE 13005
Alloc PE / Size 13005 / 406.41 GB
Free PE / Size 0 / 0
VG UUID 0Vf6Xc-j0GQ-y068-OF8a-mF1e-9jDT-yKL6ny
--- Logical volume ---
LV Name /dev/storage/space
VG Name storage
LV Write Access read/write
LV Status available
LV # 1
# open 1
LV Size 406.41 GB
Current LE 13005
Allocated LE 13005
Allocation next free
Read ahead sectors 120
Block device 58:0
--- Physical volumes ---
PV Name (#) /dev/hde1 (4)
PV Status available / allocatable
Total PE / Free PE 2980 / 0
PV Name (#) /dev/hdc1 (2)
PV Status available / allocatable
Total PE / Free PE 3576 / 0
PV Name (#) /dev/hdd1 (3)
PV Status available / allocatable
Total PE / Free PE 2980 / 0
PV Name (#) /dev/hdb3 (1)
PV Status available / allocatable
Total PE / Free PE 3469 / 0
I am able to both install, and setup lvm without any trouble at all, but it
seems the system gets really unstable. I have tried using both the Redhat
2.4.7-10 kernel (the one redhat 7.2 ships with, and the 2.4.17 kernel. I
have also tried using both lvm 1.0.2 and 1.0.3.
When reinstalling, i first export the lvm setup, do the system reinstall,
install lvm, compile new kernel, then when it is up and running, i import
the lvm setup from the other disks. All this seems to be running fine.
But when running normally, the system seems to get itself into a lot of
'Kernel Oops' problems. I have never seen these before, but now i get them
all the time. They either cause pretty much every application i try to run
after the Oops to segfault, or they simply freeze the system. When it gets
back up, and the system needs to be fsck'ed i also experience a lot of
problems getting fsck to run properly. when running fsck /dev/hda1 (which is
a normal ext2 partition, not lvm) i will get the same Kernel oops, and fsck
will fail. I will eventually get the system back up and running normally,
but it takes time. Other commands that i have seen give the same kernel oops
are umount, fsck, proftpd and smbd... I found two examples of this Kernel
Oops code in /var/log/messages, and have included them below, if anyone is
able to gather any information from them.
Any input as to why the system is so unstable would be highly appreciated.
Does the system dislike that i set the PE size to 32? Are there any problems
caused by running lvm under Redhat 7.2? (If so, I could go back to 7.1)
Kind Regards
Aslak Sommerfelt Skretting
Included:
/var/log/messages:
Feb 26 02:34:32 space sshd(pam_unix)[1217]: session closed for user tek
Feb 26 04:02:03 space syslogd 1.4.1: restart.
Feb 26 19:03:36 space sshd(pam_unix)[2639]: session opened for user tek by
(uid=0)
Feb 26 19:03:39 space su(pam_unix)[2680]: session opened for user root by
tek(uid=500)
Feb 26 19:11:49 space proftpd[2751]: space.uNF.no - ProFTPD terminating
(signal 11)
Feb 26 19:11:49 space proftpd[2751]: space.uNF.no - ProFTPD 1.2.4 standalone
mode SHUTDOWN
Feb 26 20:14:49 space su(pam_unix)[2680]: session closed for user root
Feb 26 20:14:50 space sshd(pam_unix)[2639]: session closed for user tek
Feb 26 23:24:21 space kernel: Unable to handle kernel paging request at
virtual address 802aeca8
Feb 26 23:24:21 space kernel: printing eip:
Feb 26 23:24:21 space kernel: c013e457
Feb 26 23:24:21 space kernel: *pde = 00000000
Feb 26 23:24:21 space kernel: Oops: 0000
Feb 26 23:24:21 space kernel: CPU: 0
Feb 26 23:24:21 space kernel: EIP: 0010:[link_path_walk+1703/2048] Not
tainted
Feb 26 23:24:21 space kernel: EIP: 0010:[<c013e457>] Not tainted
Feb 26 23:24:21 space kernel: EFLAGS: 00010282
Feb 26 23:24:21 space kernel: eax: 802aec80 ebx: ddebbf64 ecx: 00000000
edx: c262c1b8
Feb 26 23:24:21 space kernel: esi: c8880dc0 edi: ddebbf9c ebp: c8877820
esp: ddebbf38
Feb 26 23:24:21 space kernel: ds: 0018 es: 0018 ss: 0018
Feb 26 23:24:21 space kernel: Process smbd (pid: 2844, stackpage=ddebb000)
Feb 26 23:24:21 space kernel: Stack: 00000009 c2a7802d c8880dc0 00000000
00000000 c8880e40 00001000 fffffff4
Feb 26 23:24:21 space kernel: c2a78000 08199680 c013d89e c2a7800f
0000001e 6ea99c29 ddeba000 00000000
Feb 26 23:24:21 space kernel: c2a78000 ddebbf9c 00000009 c013ea23
ddeba000 081f9bc8 bfffea80 bfffe208
Feb 26 23:24:21 space kernel: Call Trace: [getname+94/160]
[__user_walk+51/80] [sys_stat64+20/112]
[error_code+52/60][system_call+51/56]
Feb 26 23:24:21 space kernel: Call Trace: [<c013d89e>] [<c013ea23>]
[<c013b504>] [<c010721c>] [<c010712b>]
Feb 26 23:24:21 space kernel:
Feb 26 23:24:21 space kernel: Code: 8b 50 28 85 d2 0f 84 8e 00 00 00 bb 00
e0 ff ff 21 e3 8b 93
Feb 26 23:24:35 space kernel: <1>Unable to handle kernel paging request at
virtual address 802aeca8
Feb 26 23:24:35 space kernel: printing eip:
Feb 26 23:24:35 space kernel: c013e457
Feb 26 23:24:35 space kernel: *pde = 00000000
Feb 26 23:24:35 space kernel: Oops: 0000
Feb 26 23:24:35 space kernel: CPU: 0
Feb 26 23:24:35 space kernel: EIP: 0010:[link_path_walk+1703/2048] Not
tainted
Feb 26 23:24:35 space kernel: EIP: 0010:[<c013e457>] Not tainted
Feb 26 23:24:35 space kernel: EFLAGS: 00010282
Feb 26 23:24:35 space kernel: eax: 802aec80 ebx: ddebbf64 ecx: 00000000
edx: 00000000
Feb 26 23:24:35 space kernel: esi: c8880dc0 edi: ddebbf9c ebp: c8877820
esp: ddebbf38
Feb 26 23:24:35 space kernel: ds: 0018 es: 0018 ss: 0018
Feb 26 23:24:35 space kernel: Process smbd (pid: 2856, stackpage=ddebb000)
Feb 26 23:24:35 space kernel: Stack: 00000009 dafc302d c8880dc0 08208000
00000077 00000077 00001000 fffffff4
Feb 26 23:24:35 space kernel: dafc3000 08199680 c013d89e dafc300f
0000001e 6ea99c29 ddeba000 00000000
Feb 26 23:24:35 space kernel: dafc3000 ddebbf9c 00000009 c013ea23
ddeba000 081f9bd0 bfffea80 bfffe208
Feb 26 23:24:35 space kernel: Call Trace: [getname+94/160]
[__user_walk+51/80] [sys_stat64+20/112] [error_code+52/60]
[system_call+51/56]
Feb 26 23:24:35 space kernel: Call Trace: [<c013d89e>] [<c013ea23>]
[<c013b504>] [<c010721c>] [<c010712b>]
Feb 26 23:24:35 space kernel:
Feb 26 23:24:35 space kernel: Code: 8b 50 28 85 d2 0f 84 8e 00 00 00 bb 00
e0 ff ff 21 e3 8b 93
Feb 26 23:25:42 space atd: atd shutdown succeeded
Feb 26 23:25:42 space Font Server[938]: terminating
Feb 26 23:25:43 space xfs: xfs shutdown succeeded
Feb 26 23:25:43 space rpc.mountd: Caught signal 15, un-registering and
exiting.
Feb 26 23:25:43 space nfs: rpc.mountd shutdown succeeded
Feb 26 23:25:47 space kernel: <4>nfsd: last server has exited
Feb 26 23:25:47 space kernel: nfsd: unexporting all filesystems
Feb 26 23:25:47 space nfs: nfsd shutdown succeeded
Feb 26 23:25:47 space nfs: Shutting down NFS services: succeeded
Feb 26 23:25:47 space nfs: rpc.rquotad shutdown succeeded
Feb 26 23:25:47 space sshd: sshd -TERM succeeded
Feb 26 23:25:47 space sendmail: sendmail shutdown succeeded
Feb 26 23:25:48 space smb: smbd shutdown succeeded
Feb 26 23:25:48 space smb: nmbd shutdown succeeded
Feb 26 23:25:48 space xinetd[829]: Exiting...
Feb 26 23:25:48 space xinetd: xinetd shutdown succeeded
Feb 26 23:25:48 space crond: crond shutdown succeeded
Feb 26 23:25:48 space dd: 1+0 records in
Feb 26 23:25:48 space dd: 1+0 records out
Feb 26 23:25:48 space random: Saving random seed: succeeded
Feb 26 23:25:48 space rpc.statd[580]: Caught signal 15, un-registering and
exiting.
Feb 26 23:25:48 space nfslock: rpc.statd shutdown succeeded
Feb 26 23:25:49 space portmap: portmap shutdown succeeded
Feb 26 23:25:49 space kernel: Kernel logging (proc) stopped.
Feb 26 23:25:49 space kernel: Kernel log daemon terminating.
Feb 26 23:25:50 space syslog: klogd shutdown succeeded
Feb 26 23:25:50 space exiting on signal 15
More information about the linux-lvm
mailing list