Concept and mechanism
A mount can depend on a partition, logical volume, and other layers. lsblk helps observe devices, filesystem, and UUID; df shows filesystem usage. These commands answer different questions. Expansion should begin by confirming which layer backs the application path. Extending an LV without growing the filesystem can leave visible capacity unchanged. For XFS, use the supported mounted-filesystem growth procedure, checking version, underlying capacity, and mount identity. Do not confuse expansion with creating an empty filesystem.
Guided application
fstab entries need persistent identity, correct options, and validation before reboot. UUID reduces dependence on disk enumeration, but clones can require attention to uniqueness. During change, record initial state, recovery, and success criteria: usable capacity and application operations. For networking, ip route get shows a path selection in the supplied context; it does not prove the destination responds. Network context, rules, and source addresses remain relevant. Keep the change limited to the identified resource.
Before batch, compare lsblk -f and df for the affected mount. If the LV grew but XFS did not, complete supported expansion and validate writes without recreating the filesystem.
Common pitfalls
Choosing /dev/sdX by order; confusing LV and filesystem size; editing fstab without validation; treating a route as connectivity.
Related topics: Name resolution and recovery · Services, users, and scheduling
Confirm identity and layer before making the change.
Reference: lsblk(8) · XK0-006 V8