Description of Problem: swapoff fails for swap partitions which are on LVM (such as /dev/Volume00/LogVol01). Running 'swapoff /dev/Volume00/LogVol01' gives the message that the argument is invalid. Running 'swapoff -a' returns cleanly, but doesn't turn swap off on the LVM partition. Seeing this with mount-2.11r-7. Version-Release number of selected component (if applicable): How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
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.