[linux-lvm] LVM access hangs
David
damailings at mcbf.net
Fri Feb 27 23:35:01 UTC 2004
Hi,
I just recently set up an LVM and now I'm into big trouble.
The lvm partition that I have is completely unresponsive, when I try to
access it, the kernel just hangs. I have quite a bit of data on there so
if anyone knows how I can get this back up, it would be absolutely
great.
I was using kernel 2.4.22. I created one phyiscal volume /dev/hda10,
added it to the volume group data and created a logical volume datalv
over the whole space. Then I upgraded to kernel 2.6.2 (Debian testing)
and wanted to add another physical volume.
I created the PV on /dev/hda10 and noticed that it was lvm2 while the
older one is lvm1. So I converted lvm1 to lvm2 and added the PV o the VG
data and increased the size of the LV.
I was running reiserfs, so I resized the partition. It did not want to
unmount for some reason so I resized it life (it is supported). That all
worked just fine.
Now, I even read some files from that partition but when I tried to
write something, it all crashed. When I tried to access the partition in
any way, it would not work. It was already written down in fstab and
mounts fine but any process that accesses the mount point seems to get
into a deadlock.
I think at the time of the write attempt, something crashed. I found the
following output in my logs:
----SNIP /var/log/syslog-----
Feb 25 22:16:11 tor kernel: printing eip:
Feb 25 22:16:11 tor kernel: c0194c3d
Feb 25 22:16:11 tor kernel: Oops: 0000 [#1]
Feb 25 22:16:11 tor kernel: CPU: 0
Feb 25 22:16:11 tor kernel: EIP: 0060:[<c0194c3d>] Not tainted
Feb 25 22:16:11 tor kernel: EFLAGS: 00010282
Feb 25 22:16:11 tor kernel: EIP is at scan_bitmap_block+0x3d/0x500
Feb 25 22:16:11 tor kernel: eax: 00000000 ebx: 00000000 ecx: 000000df edx: d086d000
Feb 25 22:16:11 tor kernel: esi: d086d6f8 edi: 00000001 ebp: 00000001 esp: c6297b58
Feb 25 22:16:11 tor kernel: ds: 007b es: 007b ss: 0068
Feb 25 22:16:11 tor kernel: Process smbd (pid: 2702, threadinfo=c6296000 task=ca68f8e0)
Feb 25 22:16:11 tor kernel: Stack: 00000001 c6297e10 00000018 00000000 cf6f4800 c0223db1 cfc060c0 000000df
Feb 25 22:16:11 tor kernel: c6297bb8 00000001 00000001 c01952b0 c6297d88 000000df c6297bb8 00008000
Feb 25 22:16:11 tor kernel: 00000001 00000001 00000001 00008000 00001000 00003fff 00000196 00008000
Feb 25 22:16:11 tor kernel: Call Trace:
Feb 25 22:16:11 tor kernel: [<c0223db1>] qdisc_restart+0x11/0xd0
Feb 25 22:16:11 tor kernel: [<c01952b0>] scan_bitmap+0x1b0/0x210
Feb 25 22:16:11 tor kernel: [<c0195c50>] reiserfs_allocate_blocknrs+0x1c0/0x790
Feb 25 22:16:11 tor kernel: [<c019cd59>] reiserfs_get_block+0x2d9/0x1270
Feb 25 22:16:11 tor kernel: [<c01eba32>] as_add_request+0x182/0x1f0
Feb 25 22:16:11 tor kernel: [<c01e3e7f>] __elv_add_request+0x1f/0x40
Feb 25 22:16:11 tor kernel: [<c01e6972>] __make_request+0x292/0x530
Feb 25 22:16:11 tor kernel: [<c01fafc2>] ide_build_sglist+0x32/0xc0
Feb 25 22:16:11 tor kernel: [<c011ea28>] __mod_timer+0x58/0x80
Feb 25 22:16:11 tor kernel: [<c01c5bbd>] __delay+0xd/0x10
Feb 25 22:16:11 tor kernel: [<c01f4def>] ide_execute_command+0x6f/0x80
Feb 25 22:16:11 tor kernel: [<c01fb81b>] __ide_dma_begin+0x2b/0x40
Feb 25 22:16:11 tor kernel: [<c01fe164>] __ide_do_rw_disk+0x174/0x620
Feb 25 22:16:11 tor kernel: [<c0114fe3>] schedule+0x2f3/0x530
Feb 25 22:16:11 tor kernel: [<c0148b35>] __block_prepare_write+0x1d5/0x420
Feb 25 22:16:11 tor kernel: [<c012d80e>] add_to_page_cache+0x3e/0xb0
Feb 25 22:16:11 tor kernel: [<c0149560>] block_prepare_write+0x20/0x30
Feb 25 22:16:11 tor kernel: [<c019ca80>] reiserfs_get_block+0x0/0x1270
Feb 25 22:16:11 tor kernel: [<c019fedb>] reiserfs_prepare_write+0x6b/0xa0
Feb 25 22:16:11 tor kernel: [<c019ca80>] reiserfs_get_block+0x0/0x1270
Feb 25 22:16:11 tor kernel: [<c01491b4>] generic_cont_expand+0xc4/0x140
Feb 25 22:16:11 tor kernel: [<c01a0898>] reiserfs_setattr+0x88/0x140
Feb 25 22:16:11 tor kernel: [<c01133e0>] do_page_fault+0x110/0x4ea
Feb 25 22:16:11 tor kernel: [<c015c7a8>] notify_change+0x138/0x180
Feb 25 22:16:11 tor kernel: [<c01443e0>] do_truncate+0x40/0x60
Feb 25 22:16:11 tor kernel: [<c01448b4>] sys_ftruncate64+0xc4/0x110
Feb 25 22:16:11 tor kernel: [<c0108c17>] syscall_call+0x7/0xb
Feb 25 22:16:11 tor kernel:
Feb 25 22:16:11 tor kernel: Code: 8b 00 a8 04 0f 85 7a 04 00 00 66 8b 06 89 c2 81 e2 ff ff 00
----SNAP-----
But I am not 100% certain it is related to the problem, as now when I
try to access the partition, it just hangs and I don't get an error
anymore.
And reiserfsck just quits and gives me no output. I think something is
seriously messed up here and I think it is lvm. When I do a vgdisplay, I
can see that the vg is way to full. I had just added the new pv and it
is already completely filled up even though df still shows the correct usage
level.
Please help!
Here some assorted output:
--pvdisplay--
tor:~# pvdisplay
Physical volume "/dev/hda10" of volume group "data" is exported
--- Physical volume ---
PV Name /dev/hda10
VG Name data (exported)
PV Size 27.91 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 32768
Total PE 893
Free PE 0
Allocated PE 893
PV UUID ODcmyo-FeES-58Pq-mo9b-Rbu0-47kH-Vqn9zG
--- Physical volume ---
PV Name /dev/hda9
VG Name data
PV Size 23.28 GB / not usable 0
Allocatable yes
PE Size (KByte) 32768
Total PE 745
Free PE 12
Allocated PE 733
PV UUID zkStfs-M4E9-4B4D-Qb95-M9t5-T0el-EK4vx5
--/pvdisplay--
--vgdisplay--
tor:~# vgdisplay
--- Volume group ---
VG Name data
System ID tor1076209531
Format lvm2
Metadata Areas 2
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 256
Cur LV 1
Open LV 0
Max PV 256
Cur PV 2
Act PV 2
VG Size 51.19 GB
PE Size 32.00 MB
Total PE 1638
Alloc PE / Size 1626 / 50.81 GB
Free PE / Size 12 / 384.00 MB
VG UUID C4QDlg-uKm0-kzL9-5iEw-Dfsq-0U5p-p3NZWO
--/vgdisplay--
--lvdisplay--
tor:~# lvdisplay
--- Logical volume ---
LV Name /dev/data/datalv
VG Name data
LV UUID 000000-0000-0000-0000-0000-0000-000000
LV Write Access read/write
LV Status available
# open 2
LV Size 50.81 GB
Current LE 1626
Segments 2
Allocation next free
Read ahead sectors 1024
Block device 254:0
--/lvdisplay--
Thanks,
David
More information about the linux-lvm
mailing list