Frequently Asked Questions
Please add questions here.
I get errors about /dev/mapper/control when I try to use the LVM 2 tools. What's going on?
I think I found a bug. What information should I gather and how should I report it?
Can I use pvmove on root volume ? What's special with it ?
- Problem is that move will suspend (and lock) the root volume for short periods of time, and the program must not wait for something accessing it while that is the case or you may get deadlock. Selecting certain program options can cause this to happen.
- In particular, you must not set log/activation to 1, use in-filesystem metadata stored in that filesystem or use any --verbose settings. Using -i0 to avoid unnecessary userspace code and terminal ouput may also help.
Alternatively, to perform pvmove of root device you can
Boot from different device (live cd) and perform move from here.
If not possible: prepare environment and avoid some locking issues
- obviously, backup data on the volume you are trying to move
- - try to avoid moving swap (deactivate it)
- use statically linked binaries lvm.static (and dmsetup.static) (use lvm.static pvmove <pars> instead of pvmove)
- - move these binaries to ramdisk or volume not included in root (moving) volume (keep in mind that shell runs from moving volume too !)
- - run pvmove
- you can use pvmove --abort to abandon it or pvmove [or with same source pv as before] to retry.
- If it fails (or gets stuck)
- - if you reset machine, pvmove will restart automatically.
- (dangerous): you can wake up suspended device (which caused deadlock) by running dmsetup resume <suspended device>
- If it fails (or gets stuck)
Note if you are trying to do some debugging: What you're looking for is anything that attempts to access the device being moved (e.g /dev /var /etc) while it's suspended - that process will block, and if it happens to be holding on to any resource that pvmove needs before unsuspending the device, things will lock up when pvmove tries to get that resource. It helps to get several backtraces from the deadlock situations - need to include *every* process - and look for things that they have in common. See if you can get it working in simpler environments first - e.g. disable locking in the config file; try with /etc, /dev, /var etc. in ram filesystems.
How can I debug problem myself ?
- For reporting debug information use lvm_dump (see question above)
- Common debug practices
- get version of all subsystsems (LVM/dm library/kernel driver)
lvm version uname -a
- get version of all subsystsems (LVM/dm library/kernel driver)
reproducing problem with debug messages enabled set in lvm.conf
log { ... activation = 1
- and run command with debug switches
<command> -vvvv
- Get info about device mapper state
dmsetup info -c [--noopencount] dmsetup table dmsetup status
Sometimes adding --noopencount avoids the hang of dmsetup
- Provide process and memory information from kernel
echo t > /proc/sysrq-trigger echo m > /proc/sysrq-trigger ls -R /sys/block/dm*
I see "reload ioctl failed", what's wrong ?
- If you get
device-mapper: reload ioctl failed: Invalid argument
- .. and you recently updated kernel/lvm/device-mapper Check for versions (and update all components)
kernel
device-mapper package
lvm2 package
I cannot create more than X (usually 32) snapshots...
- Known problem - will be partially solved by new DM-IO interface.
- But anyway, current snapshot implementation is not properly designed for such type of operation (many snapshots will significantly slow down all IO).