LEARN. PRACTICE. GROW.Predict the change before execution
The lab creates a 64-MiB LUN backed by a RAM file. Its objective is to grow to 96 MiB while retaining identity and a previous marker. Before running the guide, draw a table containing backing, target, each path and map. Add filesystem and application to a real service’s table even though this experiment does not implement them. Intended growth is 32 MiB, not an additional 96 MiB or the sum of paths. Identify the resource by WWID and record bytes to avoid MB-versus-MiB display differences. The intended result is a sequence of verifiable states. A successful command at one layer does not automatically complete the others.
Update the target within the tested scope
Growing the file with truncate did not update the TGT LUN report in the recorded execution. The experiment retains both observations to make the difference visible. It then pauses its own I/O, takes the LUN offline and reopens the same enlarged file through this target’s specific operation. Only then does the target present the new capacity. This step is not presented as online array expansion or a guarantee of no application impact. The lab has no concurrent workload during the transition. On actual infrastructure, the operation depends on the platform and supported combination. The team should select the destination procedure and continuity criteria rather than transplanting the TGT command into every product.
Reconcile every path before the map
The guide updates only one path first. The sample shows 96 MiB on that device, 64 MiB on the other and 64 MiB on the map. This discrepancy is deliberate and should not be hidden in a report showing only the largest value. After the second rescan, both paths show 96 MiB, but the map remains 64 MiB because the experiment sets auto_resize never. Explicit map resize completes that transition. A platform with another policy may behave differently; confirm effective state. Device names are not procedure constants. On a four-path host, identify and check all four paths. Retain LUN identity alongside capacities to avoid correlating different resources.
Demonstrate new-capacity access and plan recovery
Once the map reaches 100663296 bytes, the guide reads the old marker again and writes another at 80 MiB. That offset was beyond the former 64-MiB limit and concretely exercises added space. The hash is recorded and reading is compared byte for byte. The experiment also restores an authenticated session and confirms the new marker through the map. These results measure neither every sector nor a filesystem. If an application still lacks space, follow its path through relevant layers and quotas. After using added space, blindly shrinking backing to 64 MiB would remove that region. Recovery must consider data and consumer state rather than assume every operation has a safe inverse.
# Observe the recorded transitions in content/labs/san-growth/evidence.json.
# stage path A MiB path B MiB map MiB
# initial 64 64 64
# first path rescan 96 64 64
# both paths rescanned 96 96 64
# explicit map resize 96 96 96
# auto_resize never is explicit in this lab.
# Guarded replay and setup: content/labs/san-growth/README.txt
# No filesystem or application workload is created.Backing grows to 96 MiB, but target, paths and map change only after their respective experiment operations.
Common pitfalls
Skipping a path, adding access capacities, copying sdX names or shrinking the resource after writing in the added region.
Related topics: Storage · Linux Administration · Change Management
Growth ends when service-required layers are consistent and the consumer demonstrates agreed usable capacity.
Reference: DM Multipath capacity, per-path rescan and map resize · BigSavant SAN 2026-09; selected RHEL 9, ONTAP 9 and iSCSI behavior