LVM pvmove
LVM pvmove relocates selected allocated physical extents within a volume group while preserving their logical-volume addresses.
Selection can cover a source PV, one LV's extents on that PV, or a physical-extent range. Other extents of the same LV can remain elsewhere. LVM supports relocation while volumes are in use. [1] [4] [5]
An ordinary move uses temporary mirrors and records completed segment relocations in VG metadata. After an interruption, the documented restart resumes from a checkpoint. Restarting and aborting are different choices. [2] [1]
Without --atomic, abort leaves completed segments at the destination and unfinished segments at the source. With --atomic selected when the move starts, abort retains the source placement for the selected movement. This is a placement contract, not a rollback of application writes or a point-in-time snapshot. [3] [2]
Background mode can return before relocation finishes. Check actual completion and remaining allocations before treating a source PV as evacuated. A relocation needs eligible destination extents; free space reported inside a filesystem is not destination space in the VG. A sufficient free-extent count can still fail the allocation policy; normal allocation avoids placing parallel stripes on the same PV. [1] [3]
The 2001 Volume Managers in Linux paper describes online extent relocation but warns of crash problems in that implementation. This historical warning is not a test result for modern LVM2; the checkpoint and abort contracts above come from the separately versioned LVM2 sources. [6]
Relations
Citations
- LVM2 pvmove(8): extent selection, checkpoints, abort and background completion
- LVM2 v2_03_35: pvmove temporary mirrors and placement checkpoints
- LVM2 v2_03_35: abort and atomic option contracts
- LVM2 v2_03_35: ordinary and atomic pvmove range-selection tests
- Red Hat Enterprise Linux 10: LVM architecture and online data relocation
- Teigland and Mauelshagen, Volume Managers in Linux, USENIX ATC FREENIX 2001, sections 3 and 3.1.3
Sources & caveats
- Source synthesis of LVM2 v2_03_35 and the current upstream manual, cross-checked against Red Hat Enterprise Linux 10 documentation; no native migration, crash or latency experiment.
- The upstream selection tests were inspected, not executed. Atomicity is scoped to the selected relocation, not every extent of an affected LV or a transaction on application data.
- Historical context: Teigland and Mauelshagen, USENIX ATC FREENIX 2001, sections 3 and 3.1.3. The paper is an architecture/usage survey, not a modern crash-recovery benchmark.