Bug 69916
| Summary: | swapoff doesn't understand LVM partitions | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Public Beta | Reporter: | Jay Turner <jturner> |
| Component: | kernel | Assignee: | Stephen Tweedie <sct> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | limbo | CC: | sopwith, srevivo, tim_clymo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-09-06 12:54:15 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 67218 | ||
|
Description
Jay Turner
2002-07-26 11:57:17 UTC
Can't reproduce here with a LV that I manually created and did swapon/swapoff on (as well as a full reboot) without any problems. I see similar behaviour. My system uses a single RAID-1 VG containing LV's for all filesystems except /boot (which lives on another small RAID-1 partition). As well as the LV filesystems, I also have an LV configured for use as swap. The system is booted and LVM activated by an initrd. I'm fairly certain this is caused by running vgscan when LVM is already activated and an LV is in use for swap: swapon -s Filename Type Size Used Priority /dev/vg00/lvol2 partition 524280 0 -1 In this case, I can run swapon and swapoff as many times as I like to turn swapping on and off on the LV - however, if I now run vgscan (with the swap LV in use), I get: swapon -s Filename Type Size Used Priority /dev/vg00/lvol2 (deleted) partition 524280 0 -1 Once the swap device is in "deleted" state, swapoff returns the error reported by the original poster. Unfortunately, although vgscan is not the kind of thing that gets run very often, it does get called twice by /etc/rc.sysinit during system startup as it attempts to activate LVM. Since my LVM has already started from the initrd, these bits of rc.sysinit are not necessary so I have commented them out. Obviously, a better fix would be for somebody to figure out why the vgscan has this unfortunate effect if an LV is in use as a swap device. vgscan does it, thanks. After running vgscan, the swapoff("/dev/MYLVM/lvmswap") system
call returns EINVAL.
Although I know nearly nothing about LVM, this is a kernel bug by the looks of it,
reassigning.
This is not entirely simple to fix --- the swap code works entirely on the bases of pathnames, not the underlying objects, when associating swapoff names with active swap partitions. That means that even something like swapon on an initrd then swapoff after root mount is going to fail. The fix should be localised to one place in the code, I think, but we'll need to get it accepted upstream before we can possibly include it. There's a quick and easy hack which probably works fine for our tree; awaiting feedback. I'm still seeing the old behavior with kernel-2.4.18-12.5, but the fix might not be in there. Just checking. Just checked kernel 2.4.18-14. Swapoff now works :) Unfortunately, vgscan still has the side effect of putting an active LVM-based swap partition into "deleted" state (which I guess means it isn't functional as a swap area any more) Since vgscan runs (twice) from initscripts, this is still a bit of a problem :( No, it only means that the directory entry used to set up the swap initially is now deleted. The device is still there and swap on that device will still work. |