lvscan Command in Linux: Syntax, Options & Scan Logical Volumes

lvscan lists logical volumes on the host with activation state, device path, size, and allocation policy. Use it for a quick inventory before lvdisplay or lvs.

Published

Updated

Read time 5 min read

Reviewed byDeepak Prasad

lvscan Command in Linux: Syntax, Options & Scan Logical Volumes
About lvscan lists logical volumes on the host with activation state, device path, size, and allocation policy. Use it for a quick inventory before lvdisplay or lvs.
Tested on Ubuntu 25.04 (Plucky Puffin); LVM 2.03.27(2); kernel 7.0.0-27-generic
Package lvm2 (apt/deb) · lvm2 (dnf/rpm)
Man page lvscan(8)
Privilege root / sudo
Distros

All Linux distros with LVM2 (lvm2 package).

Detailed fields: lvdisplay.

Related guide

lvscan — quick reference

Scan and list

When to use Command
List all LVs on the system sudo lvscan
Include internal LVs (mirror legs, thin metadata) sudo lvscan -a
Show block device major:minor sudo lvscan -b
Test mode — no metadata write, no activation changes sudo lvscan -t
Read metadata without write locks sudo lvscan --readonly
Scan without loading device-mapper tables sudo lvscan --driverloaded n
Continue if locking fails (cluster edge cases) sudo lvscan --ignorelockingfailure
When to use Command
Custom columns (script friendly) sudo lvs
Full LV attributes sudo lvdisplay
Activate/deactivate LVs sudo lvchange -ay / -an

Help and version

When to use Command
Show built-in usage lvscan --help
Show LVM version lvm version

lvscan — command syntax

Synopsis from lvscan --help on Ubuntu 25.04 (LVM 2.03.27):

text
lvscan
	[ -a|--all ]
	[ -b|--blockdevice ]
	[    --ignorelockingfailure ]
	[    --readonly ]
	[ COMMON_OPTIONS ]

lvscan reads VG metadata and reports LV paths. With the default driver loaded, active LVs show as ACTIVE. Needs sudo for full visibility on multi-user hosts.


lvscan — command examples

Essential List every logical volume on the host

Run without arguments to see activation state, path, size, and allocation policy (last column).

bash
sudo lvscan

Sample output:

text
ACTIVE            '/dev/ubuntu-vg/ubuntu-lv' [58.41 GiB] inherit
  ACTIVE            '/dev/labvg/datalv' [64.00 MiB] inherit
  ACTIVE            '/dev/labvg/pctlv' [48.00 MiB] inherit

ACTIVE means the device-mapper node is loaded. inherit is the default allocation policy from the VG.

Common Read Original and Snapshot labels

Snapshot pairs show their role in the status column.

bash
sudo lvscan | grep labvg

Sample output:

text
ACTIVE   Original '/dev/labvg/datalv' [64.00 MiB] inherit
  ACTIVE   Snapshot '/dev/labvg/snaplv' [16.00 MiB] inherit

The snapshot row is the -s LV; Original is the source LV.

Common Include internal logical volumes with -a

Mirror, RAID, and thin-pool layouts expose hidden component LVs. -a lists them for debugging — they are not normally mounted directly.

bash
sudo lvscan -a | head -20

On a simple linear-only host you may see the same lines as plain lvscan. On mirrored LVs extra [_mimage_*] entries appear.

Common Compare lvscan with lvs and lvdisplay

lvs is column-oriented for scripts; lvdisplay is verbose; lvscan is the quick human scan line.

bash
sudo lvs labvg
sudo lvdisplay labvg/datalv | head -15

Sample lvs output:

text
LV     VG    Attr       LSize
  datalv labvg -wi-a----- 64.00m

Pick lvscan for a fast health check across all VGs.

Advanced Test scan without changing metadata

-t prints what would be scanned without updating cache files or activating volumes — safe for read-only inspection scripts.

bash
sudo lvscan -t | grep labvg

Sample output:

text
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  ACTIVE            '/dev/labvg/datalv' [64.00 MiB] inherit

The leading TEST MODE line confirms no metadata write occurred.

Advanced Peek at metadata without locks

--readonly reads on-disk metadata without acquiring LVM write locks. LVs show as inactive because tables are not activated.

bash
sudo lvscan --readonly | grep labvg

Sample output:

text
inactive          '/dev/labvg/datalv' [64.00 MiB] inherit

Useful when inspecting a disk image or clustered VG without joining the lock manager.

Advanced Scan with device-mapper driver unloaded

--driverloaded n skips device-mapper activation — everything reports inactive.

bash
sudo lvscan --driverloaded n 2>&1 | head -5

Sample output:

text
WARNING: Activation disabled. No device-mapper interaction will be attempted.
  inactive          '/dev/ubuntu-vg/ubuntu-lv' [58.41 GiB] inherit
  inactive          '/dev/labvg/datalv' [64.00 MiB] inherit

Expect inactive even for root LVs — this is a diagnostic mode, not production state.


lvscan — when to use / when not

Use lvscan when Use something else when
  • You want a fast inventory of every LV and whether it is active
  • You are checking snapshot/origin relationships at a glance
  • You need test or readonly scan modes for automation
  • You need UUID, segment maps, or LE counts — lvdisplay
  • You are scripting custom columns — lvs -o ...
  • You need to change activation — lvchange
  • You are creating or deleting LVs — lvcreate / lvremove

lvscan vs lvs vs lvdisplay

lvscan lvs lvdisplay
Output One line per LV, activation focus Configurable columns Multi-field report
Best for Quick audit Scripts / monitoring Troubleshooting detail
Maps (-m) No Via -o seg_pe_ranges lvdisplay -m

Command One line
lvscan Scan and list LVs (this page)
lvs Columnar LV listing

lvscan — interview corner

What does lvscan show?

Each line includes activation state (ACTIVE / inactive), device path, size, and allocation policy. Snapshot rows add Original or Snapshot labels.

A strong answer is:

"lvscan is the quick inventory of all logical volumes — path, size, active or not, and policy — across every volume group."

What does inactive mean in lvscan output?

The LV metadata exists but the device-mapper table is not loaded — often because lvchange -an was used, --readonly / --driverloaded n was passed, or the LV was never activated.

A strong answer is:

"inactive means the LV is known to LVM but not activated in device-mapper — check lvchange -ay if it should be active."

When use lvscan -t or --readonly?

-t is test mode for scripts that must not touch metadata. --readonly inspects disk metadata without locks — useful for VM images or broken locking.

A strong answer is:

"-t for dry-run scans; --readonly when I need metadata without acquiring LVM write locks."

lvscan or lvs for monitoring?

lvs -o lv_name,vg_name,lv_size,lv_attr is better for Prometheus-style metrics. lvscan is faster for an admin eyeballing the system.

A strong answer is:

"lvs with -o fields for monitoring; lvscan when I want a quick human-readable pass over every LV."


Troubleshooting

Symptom Likely cause Fix
LV missing from output Filtered VG inactive or foreign vgs -a, vgchange -ay
All LVs inactive with readonly Expected with --readonly Run plain lvscan for live state
Failed to lock VG Another host holds cluster lock --ignorelockingfailure or fix locking
Stale sizes Cached metadata vgscan --mknodes or lvchange --refresh

Rohan Timalsina

is a technical writer and Linux enthusiast who writes practical guides on Linux commands and system administration. He focuses on simplifying complex topics through clear explanations.