When managing enterprise Storage Area Networks (SANs), knowing how to find SAN disk LUN IDs in Linux is an essential skill for storage and system administrators. When a storage array team provisions a new LUN over Fibre Channel (FC) or iSCSI, Linux assigns local block device names like /dev/sdb or /dev/sdc. However, local Linux device node names are dynamic and non-persistent across reboots. To properly map storage, configure volume managers, or troubleshoot failed paths, you must identify the underlying SAN LUN ID and World Wide Identifier (WWID).
In this administrator guide, you will learn step-by-step how to scan for new storage, find SAN disk LUN IDs, map SCSI bus addresses, and correlate Linux multipath devices back to storage array LUN numbers.
Accurate LUN identification prevents catastrophic data loss by ensuring you never format or reconfigure the wrong storage device.
Understanding SAN LUN IDs vs Linux Device Names
Before executing CLI commands, it is crucial to understand the difference between logical unit numbers (LUNs), SCSI addresses, and Linux device nodes. A LUN (Logical Unit Number) is an address assigned by the storage array (such as NetApp, Pure Storage, or Dell PowerStore) to represent a specific virtual disk.
When Linux discovers this storage over the SAN fabric, it creates a SCSI block device entry under /dev/sd*. However, relying on device names like /dev/sdb creates severe risks:
- Non-persistent Naming: Kernel initialization order determines whether a disk becomes
/dev/sdbor/dev/sdc. Adding or removing a PCI card or host bus adapter (HBA) can shift device names across reboots. - Multiple Paths: In a redundant SAN environment with Device Mapper Multipath, a single LUN accessed over four Fibre Channel paths appears as four separate
/dev/sd*devices. - Unique Identifier (WWID): Every SAN LUN possesses a globally unique World Wide Identifier (WWID) embedded in its SCSI page 0x83 inquiry data. Linux uses this WWID to aggregate paths into a single multipath device (e.g.,
/dev/mapper/mpatha).
Understanding these layers fits into the broader SAN storage architecture that connects enterprise arrays to Linux hosts.
How to Scan and Discover New SAN LUNs in Linux
When a storage administrator allocates a new LUN on the storage array, Linux does not automatically detect the new block device until you perform a SCSI rescan. You can scan for new storage without rebooting the Linux host using native sysfs interfaces or utility scripts.
1. Rescanning SCSI Hosts via Sysfs
To manually trigger a scan across all Fibre Channel or iSCSI host bus adapters, echo the wildcard scan string "- - -" (channel, target, LUN) into the host scan attribute:
for host in /sys/class/scsi_host/host*/scan; do
echo "- - -" > "$host"
done
This command instructs the Linux SCSI subsystem to probe every bus, target, and LUN on all connected HBAs.
2. Using the rescan-scsi-bus.sh Script
If you have the sg3_utils package installed on Red Hat Enterprise Linux (RHEL), CentOS, Ubuntu, or SUSE, you can use the interactive helper script:
sudo rescan-scsi-bus.sh -a
The -a flag forces the script to scan all targets and display newly discovered SCSI devices along with their host addresses and LUN IDs.
Finding SAN Disk LUN IDs using lsscsi and /dev/disk/by-id
Once the host detects the SCSI devices, the fastest way on how to find SAN disk LUN IDs in Linux is by querying the SCSI device hierarchy with lsscsi.
1. Querying Storage Layout with lsscsi
The lsscsi utility summarizes all SCSI devices in a clean tabular format. Run the command with the -g flag to show generic SCSI device names as well:
lsscsi -g
Example command output:
[2:0:0:0] disk NETAPP LUN C-Mode 9700 /dev/sda /dev/sg0
[2:0:0:1] disk NETAPP LUN C-Mode 9700 /dev/sdb /dev/sg1
[3:0:1:0] disk PURE FlashArray 8800 /dev/sdc /dev/sg2
[3:0:1:5] disk PURE FlashArray 8800 /dev/sdd /dev/sg3
In the bracketed tuple [H:C:T:L]:
- H (Host): Host bus adapter index (e.g., 2 or 3).
- C (Channel): SCSI channel number (typically 0).
- T (Target): Storage array port target ID.
- L (LUN ID): The actual SAN LUN ID allocated on the storage array (e.g., LUN 0, LUN 1, or LUN 5).
The last digit in the SCSI address bracket [H:C:T:L] represents the exact SAN LUN ID assigned by the storage array.
2. Inspecting /dev/disk/by-id Symlinks
Linux udev automatically maintains persistent device symlinks in /dev/disk/by-id/. You can list these symlinks to correlate Linux sdX devices directly with world-wide identifiers and LUN numbers:
ls -l /dev/disk/by-id/
Example symlink mapping:
lrwxrwxrwx 1 root root 9 Oct 24 10:15 scsi-3600a098038304437642b4d6f4d546b31 -> ../../sdb
lrwxrwxrwx 1 root root 9 Oct 24 10:15 wwn-0x600a098038304437642b4d6f4d546b31 -> ../../sdb
Here, 3600a098038304437642b4d6f4d546b31 is the SCSI WWID. You can cross-reference this WWID with the storage array management portal (such as Unisphere, System Manager, or Pure GUI) to confirm exact volume mapping.
Mapping LUN IDs and WWIDs with multipath -ll
In enterprise SAN environments, servers connect to storage via dual HBAs and redundant fabric switches. Device Mapper Multipath aggregates redundant physical paths into a unified multipath device. Understanding how multipath maps these paths is crucial when troubleshooting iSCSI LUN discovery and configuration.
Displaying Detailed Multipath Topography
To inspect active multipath mappings, execute:
sudo multipath -ll
Example multipath output:
mpatha (3600a098038304437642b4d6f4d546b31) dm-2 NETAPP,LUN C-Mode
size=500G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
|- 2:0:0:1 sdb 8:16 active ready running
|- 2:0:1:1 sde 8:64 active ready running
|- 3:0:0:1 sdg 8:96 active ready running
`- 3:0:1:1 sdj 8:144 active ready running
Analysis of this multipath topology:
- Multipath Alias:
mpathamapped to device mapper node/dev/mapper/mpatha(or/dev/dm-2). - SAN WWID:
3600a098038304437642b4d6f4d546b31. - Physical Devices: Four paths (
sdb,sde,sdg,sdj). - LUN ID: Looking at the SCSI address suffix
2:0:0:1, the fourth number is1, confirming this multipath device corresponds to SAN LUN ID 1.
Matching WWIDs and SCSI Serial Numbers via udevadm and scsi_id
If lsscsi or multipath tools are unavailable on a minimal Linux installation, you can extract the LUN serial number and WWID directly from low-level system utilities.
1. Extracting Page 0x83 WWID using scsi_id
The scsi_id command queries the SCSI device VPD (Vital Product Data) page 0x83 directly:
/lib/udev/scsi_id --g --s /block/sdb
Output:
3600a098038304437642b4d6f4d546b31
This WWID matches the vendor volume serial number on the SAN array.
2. Querying Block Attributes with udevadm
You can query complete udev properties for any disk node using udevadm:
udevadm info --query=all --name=/dev/sdb
Look for the following properties in the output:
E: ID_WWN=0x600a098038304437
E: ID_SERIAL=3600a098038304437642b4d6f4d546b31
E: ID_MODEL=LUN_C-Mode
E: ID_VENDOR=NETAPP
E: ID_SCSI_COMPAT=3600a098038304437642b4d6f4d546b31
For official Red Hat Enterprise Linux system guidelines on storage troubleshooting, consult the Red Hat Knowledgebase guide on SAN LUN identification.
Troubleshooting Mapped Storage and Path Failures
During storage maintenance, array migrations, or LUN unmapping, Linux hosts may retain stale device paths or fail to clean up multipath maps. Here is how to handle common troubleshooting scenarios.
1. Removing Stale Block Devices
If a LUN is unmapped on the storage array before being removed from Linux, paths enter an offline or failed state. To cleanly delete a stale block device from Linux without rebooting, write 1 to its delete file:
echo 1 | sudo tee /sys/block/sdb/device/delete
2. Flushing Unused Multipath Devices
To flush a specific multipath device map after removing underlying paths, run:
sudo multipath -f mpatha
To flush all unused multipath maps across the system:
sudo multipath -F
Always ensure file systems are unmounted and LVM logical volumes are deactivated before flushing multipath devices.
Key Takeaways & Storage Mapping Summary Checklist
When working with enterprise SAN storage in Linux, keep this handy quick-reference checklist nearby:
- Rescan HBAs: Run
sudo rescan-scsi-bus.sh -aor echo"- - -"to/sys/class/scsi_host/host*/scan. - Identify LUN ID: Check the 4th digit in
lsscsi -gtuple[Host:Channel:Target:LUN]. - Verify WWID: Match
/dev/disk/by-id/symlinks ormultipath -llWWID output with your storage array LUN serial number. - Use Persistent Names: Always build LVM Physical Volumes (PVs) or file systems on
/dev/mapper/mpathXmultipath devices, never directly on individual/dev/sdXpath nodes.