Change an LVM Logical Volume Safely with lvchange

lvchange can flip a permission or reactivate an LV mid-incident, and the wrong option can interrupt everything on top of it. The examples match LVM 2.03.16(2), dated 18 May 2022, from the installed lvm2 package.

Allow about fifteen minutes. You need an existing volume group and logical volume, the lvm2 tools, and a root shell or sudo access for changes. Reading reports is normally unprivileged, but activation and metadata changes generally require elevated privileges. Do not run these examples against a mounted production filesystem until you have checked its service and mount dependencies.

1. Set the target and inspect it

Use the volume group and logical volume name as one positional argument. Replace the obvious placeholder with a real LV from your host:

$ VG_NAME='vg_example'
$ LV_NAME='lv_data'
$ LV_PATH="$VG_NAME/$LV_NAME"
$ lvs -o vg_name,lv_name,lv_attr,lv_size,lv_active,autoactivation "$LV_PATH"
  VG_NAME   LV_NAME  Attr       LSize Active AutoAct
  vg_example lv_data -wi-a----- 20.00g active  enabled

The columns and values are host-specific. The important check is that the report names the LV you intended to touch. lvchange also accepts a VG, tag or selection expression, any of which can affect more than one object, so start with one explicit VG/LV path.

Checkpoint: stop if lvs reports the wrong VG, LV type or active state. A logical volume path is not a filesystem path, and changing an LV can affect every filesystem, swap area or virtual machine using it.

2. Confirm the command version and option shape

Check the binary that will run and the local version before relying on any example, including this one:

$ command -v lvchange
/usr/sbin/lvchange
$ lvchange --version
  LVM version:     2.03.16(2) (2022-05-18)
  Library version: 1.02.185 (2022-05-18)

For the full local synopsis, use lvchange --help. This release groups the command into separate operations: general attributes, activation, refresh, monitoring, polling and RAID maintenance. Do not combine options from different operations just because they happen to appear in the same help output.

Before a metadata change, make sure automatic metadata backup is enabled. The manpage strongly advises --autobackup y, which is the normal default, but making it explicit in the command is cheap insurance. The backup is not a substitute for a filesystem or application backup, but it gives you an LVM metadata recovery point.

3. Preview a safe attribute change

The --test option disables metadata writing while still returning a success status. Use it to check command syntax and the target before applying a general attribute change:

$ sudo lvchange --test --autobackup y --permission r "$LV_PATH"
  TEST MODE: Metadata changes are not written.
$ printf 'test status: %s\n' "$?"
test status: 0

Test mode can produce unusual messages during multi-stage operations, because a tool may expect to read back a change that was deliberately never written. Treat a zero status as a successful dry run, not proof the real operation will succeed in every device or locking state.

Checkpoint: inspect the current permission before applying the change:

$ lvs -o lv_name,lv_attr "$LV_PATH"
  LV_NAME  Attr
  lv_data  -wi-a-----

The exact attribute string varies by LV type. Do not try to decode every character from memory; use the named report fields instead.

4. Make an LV read-only, then restore it

Warning: changing permissions can disrupt applications that expect to write. Check mounts and service owners first. If the LV holds a mounted read-write filesystem, stop its writers and follow the filesystem's own procedure before changing the block device permission.

$ findmnt --source "/dev/mapper/${VG_NAME}-${LV_NAME}" || true
$ sudo lvchange --autobackup y --permission r "$LV_PATH"
  Logical volume "$LV_PATH" changed.
$ lvs -o lv_name,lv_permissions,lv_attr "$LV_PATH"
  LV_NAME  Permissions  Attr
  lv_data  readonly     -wi-a-r---

The short form documented by the manpage is lvchange -pr VG/LV. The long form is easier to review in a change record. This operation changes the LV permission recorded by LVM; it does not replace filesystem-level read-only handling.

Undo the example by setting the permission back to read-write, once you have confirmed the consuming service is ready:

$ sudo lvchange --autobackup y --permission rw "$LV_PATH"
$ lvs -o lv_name,lv_permissions "$LV_PATH"
  LV_NAME  Permissions
  lv_data  rw

If the command fails after a metadata problem, do not repeatedly force it. Review the error, check locks and devices, and use the automatic LVM backup with vgcfgrestore only as a deliberate recovery procedure after preserving the current metadata.

5. Activate or deactivate an LV deliberately

An active LV is available through a device-mapper block device, usually a /dev/VG/LV symbolic link. Activating or deactivating it changes live kernel state and can interrupt anyone using the device.

$ sudo lvchange --activate y "$LV_PATH"
$ lvs -o lv_name,lv_active,lv_attr "$LV_PATH"
  LV_NAME  Active Attr
  lv_data  active -wi-a-----

To make it unavailable, first stop every consumer and unmount filesystems safely, then deactivate it:

$ sudo lvchange --activate n "$LV_PATH"
$ lvs -o lv_name,lv_active "$LV_PATH"
  LV_NAME  Active
  lv_data  inactive

The --activate ay form is for autoactivation requests generated by system tools. Autoactivation is enabled by default unless a VG or LV property, or the lvm.conf auto_activation_volume_list, prevents it; display the property with lvs -o lv_name,autoactivation. Do not use --activationmode partial as a routine workaround: it permits activation with missing physical volumes and is meant for recovery or repair, not everyday use.

Undoing the deactivation is the activation command above. If activation fails, check pvs, vgs, lvs and the system logs for missing devices or locking problems. Avoid --partial unless you understand the recovery consequences for this LV.

6. Use tags and selections only after a single-LV test

Tags earn their keep once the same policy applies to several LVs. Add a tag to one known target, verify it, and only then use the tag in a later command:

$ sudo lvchange --autobackup y --addtag maintenance "$LV_PATH"
$ lvs -o lv_name,lv_tags "$LV_PATH"
  LV_NAME  LV Tags
  lv_data  maintenance

Remove it with the inverse operation:

$ sudo lvchange --autobackup y --deltag maintenance "$LV_PATH"
$ lvs -o lv_name,lv_tags "$LV_PATH"
  LV_NAME  LV Tags
  lv_data  -

A tag or --select expression can select multiple objects at once. Count the intended matches with an lvs report before running a state-changing command. Keep --force and --yes out of ordinary scripts: they override protections and confirmations, and the manpage marks both as requiring extreme caution.

7. Know when refresh, RAID and cache options apply

lvchange --refresh VG/LV reactivates an LV using the latest metadata. It is a targeted maintenance action, not a general repair command. RAID-specific operations such as --syncaction check, --syncaction repair, --resync and --rebuild can read or rewrite large amounts of data and may run for a long time. Use them only after confirming the LV type with lvs -o lv_name,lv_attr,lv_health_status and following your storage recovery procedure.

Cache, thin-pool and VDO options carry different data-loss and performance boundaries again. --cachemode writeback can acknowledge writes still sitting in the cache before the origin has them. --errorwhenfull changes thin-pool behaviour when space runs out. These are design decisions, not harmless tuning switches: test them on the actual LV type and keep a rollback plan.

Done means