Concept and mechanism
Storage has multiple identities and limits. A name such as /dev/sdb can change with enumeration; confirm attributes and use validated persistent identifiers. Clones can duplicate UUIDs, so identifiers also need context. A larger LV does not imply a larger filesystem if growth of that layer was neither requested nor completed. Identify the filesystem and supported procedure before intervention; recreating a filesystem is not a safe way to enlarge it. With thin provisioning, virtual capacity is not physical capacity. Observe pool Data% and Meta%, trends, monitoring, and extension options. Nearly exhausted metadata can require action even when data appears to have headroom.
Guided application
Remote access adds conditions. In an NFS example using AUTH_SYS and root_squash, client root does not automatically receive server-root privilege. Align application identity and permissions; disabling squash for every failure broadens trust without diagnosis. In iSCSI, discovering a target does not demonstrate LUN presentation to the initiator. Confirm IQN, ACLs, and mapping before touching disks. In a fictional metadata-alert scenario, VG space and a validated backup exist. The response combines supported extension, subsequent validation, and prevention of unexpected growth. Never select a device for formatting solely by name order or size: those clues prove neither role nor content.
Moderate Data% and critical Meta% require attention to the resource actually constrained.
Common pitfalls
Name as identity; LV as filesystem; virtual capacity as physical headroom; discovery as authorization.
Related topics: Automate with evidence · Operate and recover systems · Identity, PAM, and SSH
Confirm the layer and resource before changing capacity or access.
Reference: LVM thin pool capacity · Historical LFCE V3.18 (2018-06-12); exam retired 2022-05-01; technical references inspected 2026-09-30