LEARN. PRACTICE. GROW.Write and read through the map
The guide creates an original 4096-byte marker and writes it through /dev/mapper/dr_san_lab. The write uses direct I/O and conv=fsync; the following read uses direct I/O and compares bytes with the expected value. The report also records SHA-256 for comparing phases. Writing directly through an sdX path would bypass the layer being observed. Identity checks repeat before every operation rather than only during preparation. The result establishes reading this block in the tested environment. It establishes neither integrity of every sector, persistence after power loss nor application transaction outcomes. The backing store is in VM RAM, so destroying the VM removes the exercise resource.
Remove access in an orderly way
After the first correct read, the guide ends only the session associated with portal A. It waits for a bounded period until the map and SCSI presentation show one path. It reads the previous marker again and writes a second marker through the degraded map, then confirms content. The record combines session state, topology and I/O, avoiding an availability conclusion based only on the map name. This is orderly session removal. It is not abrupt cable disconnection, controller loss or power failure. Both portals share a kernel, target process and backing file. In a real situation, specify which failure domain to evaluate and which workload must continue before selecting the corresponding experiment.
Restore the path and verify convergence
Logging into portal A again is one recovery stage. A successful command response may precede events that make the second path appear in the map. The guide therefore waits until it observes two paths, with a time limit and explicit failure if convergence fails. Only then does it read the second marker again and confirm LUN identity. In a fictional maintenance ticket, communicate available access and restored redundancy separately. If the deadline expires with only one confirmed path, do not hide the difference by changing the dashboard’s expected value. Record the deviation, owner, next check and window decision. Reading through the survivor is evidence of current access, not automatic authorization to remove that last path.
Clean up, repeat and hand over to RUN
Cleanup is part of the result. Because the experiment creates no mounts or LVM, it ends I/O, removes the map, closes identified sessions and deletes its target. It then removes lab node records, stops its daemons and restores the two saved configuration files. It checks that SCSI disks, map and backing file are absent. A second run repeats all nine checks with fresh resources. For handover, include versions, a hash-identified script, results and limitations. The course’s eight historical models remain offline models; this lab adds bounded Linux execution. A banking migration still needs representative application, reconciliation, recovery, load and RUN-autonomy evidence. A human workshop and independent specialist review remain outstanding.
# Evidence directory: content/labs/san-runtime
# Inspect evidence.json and evidence-repeat.json after replay.
# Groups: parserDiagnostics, discoveryWithoutSession, singleSession,
# twoPathsOneIdentity, multipathMap, directIO,
# orderlyPathRemoval, pathRejoin, cleanup.
# Confirm: bytes=67108864; remainingPaths=1; restoredPaths=2.
# Compare the recorded marker SHA-256 values across phases.
# Scope: orderly logout; no abrupt physical failure was injected.The marker remains readable with one path. The second login finishes before the first sample shows both aggregated paths.
Common pitfalls
Treating logout as cable removal, a marker read as database integrity or two loopback addresses as two fabrics.
Related topics: Linux Administration · Production Support L3 · High Availability
A result is useful when it explains what ran, what was observed and which acceptance criteria remain unproven.
Reference: DM Multipath: identity, topology and lifecycle · BigSavant SAN 2026-09; selected RHEL 9, ONTAP 9 and iSCSI behavior