Bug 247112
Summary: | expand logical volume fails: lvresize failed: failed to suspend {lvname} | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Timms <dtimms> | ||||||||||||||
Component: | system-config-lvm | Assignee: | Jim Parsons <jparsons> | ||||||||||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||||
Priority: | low | ||||||||||||||||
Version: | 7 | CC: | mbroz, triage | ||||||||||||||
Target Milestone: | --- | ||||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | athlon | ||||||||||||||||
OS: | Linux | ||||||||||||||||
Whiteboard: | |||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2008-06-17 01:47:57 UTC | Type: | --- | ||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
Embargoed: | |||||||||||||||||
Attachments: |
|
Description
David Timms
2007-07-05 14:12:09 UTC
Created attachment 158591 [details]
dialog settings for lv resize.
Created attachment 158593 [details]
visual map of the vg/lv usage and space.
Created attachment 158594 [details]
var/log/messages events and fdisk layout.
Created attachment 159108 [details]
gkrellm visual disk usage over 4x minutes during scan
Disk usage during the scan seems to average around 300KB/sec for each disk.
=====
when the resize fails, the following is logged:
Jul 13 08:04:33 poweredge yum : Installed: strace.i386 4.5.15-1.fc7
Jul 13 08:33:08 poweredge kernel: device-mapper: table: device 8:5 too small
for target
Jul 13 08:33:08 poweredge kernel: device-mapper: table: 253:1: linear:
dm-linear: Device lookup failed
Jul 13 08:33:08 poweredge kernel: device-mapper: ioctl: error adding target to
table
=====
dmesg:
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (8192 buckets, 65536 max)
e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control:
RX/TX
audit(1184191640.355:4): audit_pid=2167 old=0 by auid=4294967295
subj=system_u:system_r:auditd_t:s0
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted)
[<c042b0cf>] local_bh_enable+0x45/0x92
[<c06002bd>] cond_resched_softirq+0x2c/0x42
[<c059adf3>] release_sock+0x4f/0x9d
[<c05cec7d>] tcp_send_ack+0xeb/0xef
[<c05c7755>] tcp_recvmsg+0x8d2/0x9de
[<c059a7a9>] sock_common_recvmsg+0x3e/0x54
[<c0598839>] sock_aio_read+0xfc/0x108
[<c04755f8>] do_sync_read+0xc7/0x10a
[<c0436e71>] autoremove_wake_function+0x0/0x35
[<c0475e99>] vfs_read+0xba/0x152
[<c04762db>] sys_read+0x41/0x67
[<c0404f70>] syscall_call+0x7/0xb
=======================
Bluetooth: Core ver 2.11
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
eth0: no IPv6 routers present
device-mapper: table: device 8:5 too small for target
device-mapper: table: 253:1: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table
device-mapper: table: device 8:5 too small for target
device-mapper: table: 253:1: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table
I hadn't noticed the bug bit before, but is it related - i htink it was during
the last reboot - but dmesg doesn't give timing.
Created attachment 159109 [details]
strace 30MB log bzipped to 851KB!
I see lots of:
(4, "5\20\4\0\33\nf\2\354\0`\2\226\0\24\0\226\4\5\0\34\nf\2"..., 5272) = 5272
read(4, 0xbf85298c, 32) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(4, "\1\20\345\367(\1\0\0\0\0\0\0\260\361\271\t(W\216\277|\225"..., 32) =
32
readv(4, [{"\26\306\26\316\26\316\26\316\26\316\26\316\26\316\26\316"...,
1184}, {"", 0}], 2) = 1184
write(4, "I\2\5\0$\nf\2\0\0\0\0\224\0\22\0\377\377\377\377", 20) = 20
read(4, 0xbf8524cc, 32) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(4, "\1\10\346\367\232\2\0\0\0\0\0\0T\325C\10(W\216\277|\225"..., 32) = 32
readv(4, [{"\205\371\377\377\377\377\377\377\377\377\377\377\377\377"...,
2664}, {"", 0}], 2) = 2664
write(4, "7\2\5\0/\nf\2\357\1`\2\0\0\1\0\0\0\0\0H\2.\1\357\1`\2/"..., 1372) =
1372
read(4, 0xbf85298c, 32) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(4, "\1\20\360\367$\0\0\0\0\0\0\0\300\35\304\t(W\216\277|\225"..., 32) = 32
readv(4, [{"\325\275\224\275\224\275\224\275\325\305\325\305\325\305"..., 144},
{"", 0}], 2) = 144
write(4, "I\2\5\0$\nf\2\0\0\0\0\224\0\22\0\377\377\377\377", 20) = 20
read(4, 0xbf8524cc, 32) = -1 EAGAIN (Resource temporarily
unavailable)
Ok - first, thank you for the prompt log output. Sometimes, these types of device mapper errors indicate multipath or md problems, where more than one device *should* be merged together with LVM2 layered on top; but the merging hasn't happened so LVM2 is left using the underlying devices that are not the expected size. We need to get medieval with this problem - we need to try 'lvmdump'... that's a script I ask people to run to gather diagnostics. We need to look for things like md devices in there, at aren't being assembled, or that are filtered out wrongly in lvm.conf. lvmdump is in the latest releases, and is also in the sources cvsweb repo. Here is a link to the man page: http://linux.die.net/man/8/lvmdump I kinda think this is not related to the UI, but i'll hang in here with you :) BTW, thx for using the GUI Created attachment 159263 [details]
lvmdump -a -m
I think I missed mentioning that running the command the the gui mentioned it
had trouble on fails as well {same error message}, the difference being once
the error message appears, it doesn't try to "reload lvm" config, so it only
takes a few minutes not like 6 minutes.
I guess the gui is out of it as long as the attempted command is legit.
===
more info on the machine - in case it is useful:
dell poweredge 1600SC
5x36G disks on SCSI
adaptec controller:
2x in hw RAID 1 {/dev/sda}
1x {/dev/sdb}
1x {/dev/sdc/
lsi controller:
1x {/dev/sdd}
===
also ran an fsck.ext3 -f on the two lvm volumes; it says structure is ok.
Does the lack of ~disk errors~ in /varlog/messages guarantee the disks are good ? Is it worth destructively scanning the disk(s) for errors with badblocks -w ? Is there smart capabilities on scsi disks ? This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Probably shortly after F8 release, the machine was upgraded, and hence no longer runs F7. This problem wasn't seen with F8 {instead just slow access when scanning the lvm volumes due to the ~over the top number of lvm partitions on each physical disk that was making up the lvs. Additionally, /dev/sdd disk4 has begun having read errors, so I took the opportunity to recreate the lvm config with each of the 3 remaining disks having only two lvm partitions {instead of 10}. The LVs are resizing without error, so I am happy for the issue to be closed if the maintainer doesn't want to actively track the issue. Thanks. Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |