|
Bugzilla – Full Text Bug Listing |
| Summary: | lvm: Making a vg unavailable sometimes fails if it was used before | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.1 | Reporter: | Forgotten User 7XRNh5WElB <forgotten_7XRNh5WElB> |
| Component: | Basesystem | Assignee: | Guangliang Zhao <gzhao> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | forgotten_7XRNh5WElB |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Output of "vgchange -an testvg -vvvvvvvvvvvvvvvv" (stdout+stderr) | ||
Hi reporter, Can you collect the log when vgchange fails? Created attachment 469304 [details] Output of "vgchange -an testvg -vvvvvvvvvvvvvvvv" (stdout+stderr) Hi GuangLiang Zhao, > Can you collect the log when vgchange fails? Here is the very-verbose output of vgchange --- I hope that's what you ment. There are no messages about this in /var/log/messages or in dmesg. Yarny Hi Yarny, Failure of vgchange should be caused by udev rules. I am fixing it now. Best regards, Guangliang Zhao (In reply to comment #3) > Created an attachment (id=469304) [details] > Output of "vgchange -an testvg -vvvvvvvvvvvvvvvv" (stdout+stderr) > > Hi GuangLiang Zhao, > > Can you collect the log when vgchange fails? > Here is the very-verbose output of vgchange --- I hope that's what you ment. > There are no messages about this in /var/log/messages or in dmesg. > Yarny Hi Yarny, Mkswap will trigger an event of udev, because the swap partition is a device-mapper device. I think you need to use "udevadm settle" to wait that udev's finishing to prevent from race condition. your script should be like this: DEV=/dev/sda dd if=/dev/zero of=$DEV bs=1K count=1K pvcreate $DEV vgcreate testvg $DEV lvcreate -l 100%VG -n testlv testvg mkswap -f /dev/testvg/testlv + udevadm settle vgchange -a n testvg Hi Guangliang Zhao, with udevadm as given in your comment 5, I couldn't reproduce the problem. What stumps me a bit is that udev-settle is also needed without mkswap (see my initial report). Certainly lvcreate causes some udev event when /dev/testvg/testlv is made active, but wouldn't it be natural for lvcreate to wait for udev to finish whatever it is doing before exiting? As a user of lvcreate I expect the device to be ready (e.g. ready for deactivation) when lvcreate returns. And the same goes for mkswap: From a user-perspective, mkswap just writes some bytes to the swap device, so when it uses the device-mapper internally, it should also wait for all udev-events to be processed before returning. Yet I'm far from being an expert in udev things, so if there are other reasons why mkswap and lvcreate cannot or should not wait for udev, I'm sorry for inconveniences and feel free to close this bug as INVALID. Thanks and best wishes, Yarny close |
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 When I create a LVM volume group and a logical volume, and then try to set the volume group unavailable (with "vgchange -a n"), this sometimes fails. Reproducible: Sometimes Steps to Reproduce: I tested this in a VirtualBox (hosted on oS 11.4) with a fresh 48GiB harddisk, which is booted from November's 12.1 KDE-LiveCD. Caution: This destroys /dev/sda ! Run this: ################################################################ DEV=/dev/sda dd if=/dev/zero of=$DEV bs=1K count=1K pvcreate $DEV vgcreate testvg $DEV lvcreate -l 100%VG -n testlv testvg mkswap -f /dev/testvg/testlv vgchange -a n testvg ################################################################ Actual Results: Can't deactivate volume group "testvg" with 1 open logical volume(s) Expected Results: 0 logical volume(s) in volume group "testvg" now active It only fails if this script is saved to a file and executed as a whole by bash. Manually typing in the commands is too slow. To repeat the script after a failure ("Can't deactivate..."), you will have to wait a few seconds, then again "vgchange -a n testvg", which should succeed. It does not always fail. Here's what I observed. After booting the machine, the script succeeds several times. After maybe a dozen cycles of the script, it suddenly fails for the first time, and then it fails in most cases. mkswap seems to be innocent. After a reboot, I couldn't get it to fail without the mkswap-line, but after the first failure, it mostly fails even without the mkswap-line. I'm quite sure there is a race-condition involved somewhere. I retried it with a loop-device that is backed by a file in /tmp. On the Live-CD such a file resides entirely in memory I understand. It never failed on this device. Then I created an ext4 on /dev/sda and used a file on this fs for a loop device. There it failed, but I had the impression that it failed less often.