Concept and mechanism
An LVM operation starts by identifying the device and existing layers. Before creating a PV, confirm serial or persistent identity, signatures, and usage; the first available /dev/sdX name is insufficient evidence. A VG supplies extents for LVs. If 6 GiB are free and an extension requires 10 GiB, at least another 4 GiB of usable capacity is needed, considering granularity and allocation constraints. Extending the LV and growing the filesystem are separate steps. For XFS, supported growth applies to the mounted filesystem; verify the correct mount and underlying capacity.
Guided application
Persistent configuration should point to the intended filesystem. Compare observed UUID and fstab, validate options and dependencies before reboot, and prevent the application from writing to the underlying directory when the mount is missing. Activating swap now likewise does not prove future activation. In NFS, root_squash can map client-root requests to an anonymous identity; local root does not guarantee remote access. With autofs, the mount may appear only when its path is accessed. Interpret absence before access according to that mechanism rather than immediately declaring a boot failure.
For a reconciliation volume, confirm identity with lsblk -f, capacity with df, and persistence in a reboot rehearsal. These checks complement one another.
Common pitfalls
Recreating a filesystem to fix a UUID; confusing LV and filesystem; ignoring root_squash; accepting runtime-only swap.
Related topics: Services, time, and boot maintenance · Network profiles and durable rules
Validate identity, usable capacity, access, and persistence separately.
Reference: fstab(5): filesystem table · EX200 based on Red Hat Enterprise Linux 10