Lsblk: Inspecting Block Device Topologies, Auditing Storage Mount Hierarchies, and Resolving Partition Mappings in Production

The immediate panic in a storage outage is not just that the database cannot write to disk; it is the terrifying uncertainty of the machine beneath it. Over half a decade of emergency migrations and hurried infrastructure upgrades, successive engineers have bolted together blazing-fast solid-state drives, aging mechanical platters, software redundancy mirrors, and layers of disk encryption. You need to know exactly which drive is choking, how the storage layers stack up, and which volume is full—without accidentally running a destructive command against the wrong disk and turning a painful outage into a catastrophic disaster.

Traditional Unix utilities offer little solace in this moment. The classic df -h command only reports filesystems that are already successfully mounted and running, staying completely blind to unmounted drives, degraded mirrors, or raw partitions waiting in limbo. Meanwhile, low-level partition tools like fdisk -l overwhelm your screen with thousands of lines of raw sector numbers and hexadecimal codes that do nothing to explain how physical hardware connects to live directories.

This is where lsblk becomes the most critical instrument in your toolkit. The name stands for "list block devices", and its purpose is simple yet vital: it queries the Linux kernel and renders every physical disk, virtual volume, RAID array, and encryption container into an intuitive, deterministic tree hierarchy. Instead of forcing you to mentally assemble fragmented device numbers, it instantly shows you how physical silicone and spinning magnetic disks translate into active filesystem mounts.

For an immediate, life-saving diagnostic overview of any Linux system, the single most useful command to run right away is lsblk -f:

lsblk -f

NAME                    FSTYPE      LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                                 
|-sda1                  vfat        EFI         8A3C-1F2D                             488.2M     4% /boot/efi
|-sda2                  ext4        BOOT        3a2e1d74-c5b9-4b93-b789-9a2c1f5e8d9a  732.4M    21% /boot
`-sda3                  crypto_LUKS             f47ac10b-58cc-4372-a567-0e02b2c3d479                
  `-luks-f47ac10b       LVM2_member             K2e9z1-9vUo-2Lm4-7pQr-8sTu-VwXy-Z1a2b3              
    |-vg_system-lv_root ext4        ROOT        9c8b7a6f-5e4d-3c2b-1a0f-9e8d7c6b5a4f   28.4G    62% /
    |-vg_system-lv_var  ext4        VAR         1b2c3d4e-5f6a-7b8c-9d0e-1f2a3b4c5d6e   42.1G    48% /var
    `-vg_system-lv_swap swap        SWAP        0f1e2d3c-4b5a-6f7e-8d9c-0b1a2f3e4d5c                [SWAP]

In five lines of output, the fog clears. You can see physical disk sda, its EFI and boot partitions, its encrypted LUKS wrapper on partition 3, the decrypted LVM volume group inside it, and the final logical volumes powering your root filesystem and /var partition—along with their precise free space and unique filesystem identifiers.

What It Does in Plain English

Every computer stores data on "block devices"—hardware or virtual interfaces that move fixed chunks (blocks) of bytes. But modern operating systems rarely write directly to bare drives. Instead, Linux organizes storage into an architectural stack: physical drives are divided into partition slices, partitions are bundled into software RAID arrays for redundancy, those arrays are wrapped in cryptographic layers for security, and volume managers divide the decrypted space into flexible logical drives before a filesystem (like ext4 or XFS) formats them for everyday use.

Rather than forcing you to inspect each layer with a separate diagnostic tool, lsblk queries the kernel's internal device registry and maps the entire journey from physical hardware to the user-facing filesystem.

Core Flags & Quick Start

The flexibility of lsblk comes from its ability to query the Linux kernel's sysfs virtual filesystem and udev device manager without issuing slow, blocking hardware probes. By combining specific flags, you can tailor your output for human troubleshooting or automated scripts.

Production Use Cases

1. Full Block Storage Auditing & Hierarchy Inspection

Operational Scenario

During infrastructure audits, capacity planning, or pre-migration reviews, you need to catalog every storage device attached to a server. You must determine which drives are blazing-fast solid-state media and which are slow spinning platters, audit available space, and ensure every active mount uses permanent UUID identifiers rather than unpredictable device names like /dev/sda that can change between reboots.

Command Invocation

lsblk -o NAME,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINT,ROTA,TYPE,UUID

Terminal Output

NAME                         FSTYPE       SIZE FSAVAIL FSUSE% MOUNTPOINT        ROTA TYPE UUID
nvme0n1                                 931.5G                                     0 disk 
|-nvme0n1p1                  vfat         512M  488.2M     4% /boot/efi            0 part 8A3C-1F2D
|-nvme0n1p2                  ext4           1G  732.4M    21% /boot                0 part 3a2e1d74-c5b9-4b93-b789-9a2c1f5e8d9a
`-nvme0n1p3                  LVM2_member  930G                                     0 part e92f58e1-93c4-4b56-b0e2-89241bfa4910
  |-vg_nvme-lv_os            ext4          50G   28.4G    39% /                    0 lvm  9c8b7a6f-5e4d-3c2b-1a0f-9e8d7c6b5a4f
  `-vg_nvme-lv_data          xfs          880G  612.8G    30% /var/lib/containers  0 lvm  c4b3a2d1-e0f9-4876-9213-5a6b7c8d9e0f
sda                                       7.3T                                     1 disk 
`-sda1                       xfs          7.3T    2.1T    71% /mnt/backup_cold     1 part 7f6e5d4c-3b2a-1f0e-9d8c-7b6a5f4e3d2c
sdb                                       7.3T                                     1 disk 

Analytical Breakdown

• NAME: Reflects kernel device namespaces. nvme0n1 represents Non-Volatile Memory Express controller 0, namespace 1. sda and sdb represent traditional SATA/SCSI drives.
• ROTA: The rotational indicator from /sys/block/<dev>/queue/rotational. A value of 0 confirms non-rotational flash memory (NVMe/SSD); 1 indicates mechanical spinning platters.
• TYPE: Shows the device abstraction level: disk (physical hardware), part (raw partition slice), or lvm (logical volume manager target).
• FSAVAIL & FSUSE%: Shows remaining user-accessible disk space alongside current storage utilization.
• UUID: The permanent 128-bit filesystem identifier that never changes even if physical drive cables or PCI slots are swapped.

What the Admin Does Next

1. Verify that /etc/fstab exclusively references volumes by their UUID= strings so that system boots never fail if device letters swap after maintenance.
2. Note that sdb is a 7.3TB spinning disk (ROTA=1) with no partitions or filesystems (FSTYPE and MOUNTPOINT are blank). This drive is raw and unallocated, ready to be added to an archive array.

2. Deconstructing Layered Storage Architectures

Operational Scenario

Enterprise database servers often combine multiple storage technologies: physical drives form a mirrored RAID array for fault tolerance, which is locked inside dm-crypt / LUKS encryption at rest, which is then managed by LVM Logical Volume Managers for flexible partitioning. When I/O errors occur, an administrator must trace this entire hierarchy from the database directory down to the exact failing physical drive.

Command Invocation

lsblk -o NAME,TYPE,SIZE,FSTYPE,STATE,MOUNTPOINT -p

Terminal Output

NAME                                       TYPE     SIZE FSTYPE            STATE   MOUNTPOINT
/dev/nvme0n1                               disk   1.8T                     running 
|-/dev/nvme0n1p1                           part   512M vfat                        /boot/efi
|-/dev/nvme0n1p2                           part     2G ext4                        /boot
`-/dev/nvme0n1p3                           part   1.8T linux_raid_member           
  `-/dev/md0                               raid1  1.8T crypto_LUKS         clean   
    `-/dev/mapper/cr_raid0                 crypt  1.8T LVM2_member                 
      |-/dev/mapper/vg_secure-lv_root      lvm    100G ext4                        /
      |-/dev/mapper/vg_secure-lv_database  lvm    1.5T xfs                         /var/lib/postgresql
      `-/dev/mapper/vg_secure-lv_swap      lvm     32G swap                        [SWAP]
/dev/nvme1n1                               disk   1.8T                     running 
|-/dev/nvme1n1p1                           part   512M                             
|-/dev/nvme1n1p2                           part     2G ext4                        
`-/dev/nvme1n1p3                           part   1.8T linux_raid_member           
  `-/dev/md0                               raid1  1.8T crypto_LUKS         clean   
    `-/dev/mapper/cr_raid0                 crypt  1.8T LVM2_member                 
      |-/dev/mapper/vg_secure-lv_root      lvm    100G ext4                        /
      |-/dev/mapper/vg_secure-lv_database  lvm    1.5T xfs                         /var/lib/postgresql
      `-/dev/mapper/vg_secure-lv_swap      lvm     32G swap                        [SWAP]

Analytical Breakdown

• The Mirrored Foundation: Physical drives /dev/nvme0n1p3 and /dev/nvme1n1p3 are bonded into a RAID 1 mirror exposed as /dev/md0 (STATE=clean).
• The Encryption Envelope: The kernel's dm-crypt driver decrypts /dev/md0 into /dev/mapper/cr_raid0.
• Logical Volume Allocation: The decrypted container is assigned to LVM volume group vg_secure, which is carved into three logical volumes: lv_root, lv_database, and lv_swap.
• Visual Validation: lsblk displays /dev/md0 and its children identically beneath both NVMe disks, proving that both physical drives are actively maintaining the mirror.

What the Admin Does Next

If database write performance stutters, the administrator can systematically diagnose each layer in order: check filesystem health on lv_database, verify CPU encryption overhead on cr_raid0, confirm RAID rebuild status in /proc/mdstat, and inspect physical drive health using SMART telemetry on /dev/nvme0n1 and /dev/nvme1n1.

3. Structured Machine-Readable Output for Infrastructure Automation

Operational Scenario

In cloud automation, CI/CD pipelines, and configuration management tools (such as Ansible or Terraform local-exec hooks), scripts must programmatically discover block devices. Parsing raw text with awk or grep is brittle and prone to catastrophic errors if disk names or column widths shift. Structured JSON and key-value formats provide guaranteed reliability.

Command Invocations

# Generate strict JSON for programmatic parsing
lsblk -J -o NAME,PATH,SIZE,TYPE,UUID,PARTUUID,SERIAL,FSTYPE

# Generate key-value pairs for direct shell evaluation
lsblk -P -o NAME,PATH,SIZE,TYPE,UUID,SERIAL

Terminal Output (JSON: lsblk -J)

{
   "blockdevices": [
      {
         "name": "nvme0n1",
         "path": "/dev/nvme0n1",
         "size": "476.9G",
         "type": "disk",
         "uuid": null,
         "partuuid": null,
         "serial": "S43ENX0M104928D",
         "fstype": null,
         "children": [
            {
               "name": "nvme0n1p1",
               "path": "/dev/nvme0n1p1",
               "size": "512M",
               "type": "part",
               "uuid": "4A12-B3C4",
               "partuuid": "e2f1a0b3-01",
               "serial": null,
               "fstype": "vfat"
            },
            {
               "name": "nvme0n1p2",
               "path": "/dev/nvme0n1p2",
               "size": "476.4G",
               "type": "part",
               "uuid": "7b8a9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d",
               "partuuid": "e2f1a0b3-02",
               "serial": null,
               "fstype": "ext4"
            }
         ]
      }
   ]
}

Terminal Output (Pairs: lsblk -P)

NAME="nvme0n1" PATH="/dev/nvme0n1" SIZE="476.9G" TYPE="disk" UUID="" SERIAL="S43ENX0M104928D"
NAME="nvme0n1p1" PATH="/dev/nvme0n1p1" SIZE="512M" TYPE="part" UUID="4A12-B3C4" SERIAL=""
NAME="nvme0n1p2" PATH="/dev/nvme0n1p2" SIZE="476.4G" TYPE="part" UUID="7b8a9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d" SERIAL=""

Analytical Breakdown

• lsblk -J generates a strictly valid JSON tree structure where parent-child relationships are preserved inside the "children" array. Non-existent values (like a missing filesystem UUID on an unformatted drive) are safely represented as null.
• lsblk -P outputs escaped, quote-wrapped key-value pairs on individual lines, making it easy to parse parameters in shell loops without breaking on spaces or special characters.

What the Admin Does Next

Using the JSON output with jq, you can write an idempotent provisioning script that discovers an attached unformatted drive by its hardware serial number, verifies it contains no existing data, and safely prepares it:

#!/usr/bin/env bash
set -euo pipefail

TARGET_SERIAL="S43ENX0M104928D"

# Locate the disk device node matching the exact hardware serial number
DEVICE_PATH=$(lsblk -J -o PATH,SERIAL,TYPE | jq -r \
  --arg SERIAL "$TARGET_SERIAL" \
  '.blockdevices[] | select(.serial == $SERIAL and .type == "disk") | .path')

if [[ -z "${DEVICE_PATH:-}" ]]; then
  echo "ERROR: Target disk with serial ${TARGET_SERIAL} was not found." >&2
  exit 1
fi

echo "Discovered target block device: ${DEVICE_PATH}"

# Verify the device has no existing filesystems before touching it
if lsblk -no FSTYPE "${DEVICE_PATH}" | grep -q '[^[:space:]]'; then
  echo "ABORT: Device ${DEVICE_PATH} already contains active filesystem metadata." >&2
  exit 2
fi

echo "Device is clean. Ready for automated partitioning and formatting."

4. Triaging Newly Attached Cloud Volumes & Unmounted Block Devices

Operational Scenario

When provisioning virtual machines on cloud platforms like Amazon Web Services (AWS Elastic Block Store) or Google Cloud Engine (GCE Persistent Disks), engineers frequently attach new virtual block devices to running instances. Because cloud kernels assign dynamic NVMe device names asynchronously, the new disk might appear as /dev/nvme1n1 rather than the requested /dev/xvdf or /dev/sdb.

Command Invocation

lsblk -a -o NAME,MAJ:MIN,RM,SIZE,RO,TYPE,MOUNTPOINT,MODEL,SERIAL

Terminal Output

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT MODEL          SERIAL
loop0          7:0    0 24.4M  1 loop /snap/core/16202          
loop1          7:1    0 63.9M  1 loop /snap/core20/2105         
nvme0n1      259:0    0   30G  0 disk            Amazon Elastic vol01a2b3c4d5e6f7g8h
|-nvme0n1p1  259:1    0 29.9G  0 part /                          
|-nvme0n1p127 259:2   0    1M  0 part                            
`-nvme0n1p128 259:3   0   10M  0 part /boot/efi                  
nvme1n1      259:4    0  500G  0 disk            Amazon Elastic vol0987654321fedcba0

Analytical Breakdown

• -a (--all): Forces lsblk to list all kernel block devices, including read-only snap application loops (RO 1, TYPE loop).
• MAJ:MIN: Major and minor kernel numbers. Major number 259 identifies dynamic NVMe device allocations.
• SERIAL: AWS EBS exposes the unique volume identifier directly in the serial field (vol0987654321fedcba0), allowing you to correlate cloud console disks with internal Linux device nodes.
• The Triage Result: Device nvme0n1 is the 30GB root operating system disk. Device nvme1n1 is a newly attached 500GB EBS volume that currently lacks partitions, filesystems, and mount targets.

What the Admin Does Next

Initialize and persistently mount the newly discovered cloud block device:

# 1. Ensure kernel udev events have settled
udevadm settle

# 2. Apply a modern GPT partition table
parted -s /dev/nvme1n1 mklabel gpt

# 3. Create an aligned primary partition spanning the full 500GB volume
parted -s -a optimal /dev/nvme1n1 mkpart primary xfs 0% 100%

# 4. Format the partition with the XFS filesystem
mkfs.xfs -L data_store /dev/nvme1n1p1

# 5. Extract the newly generated UUID and register it in fstab
NEW_UUID=$(lsblk -no UUID /dev/nvme1n1p1)
echo "UUID=${NEW_UUID} /data xfs defaults,nofail,noatime 0 2" >> /etc/fstab

# 6. Create the directory target and mount the filesystem
mkdir -p /data
mount -a

5. Verifying I/O Topology, Sector Alignment, and Discard/TRIM Capabilities

Operational Scenario

High-throughput workloads like relational databases (PostgreSQL, MySQL) and search clusters experience severe latency spikes when partition offsets violate physical hardware sector boundaries. Additionally, when running flash storage through encryption or LVM layers, you must ensure that TRIM/discard requests pass through to the underlying SSD controller to prevent performance degradation over time.

Command Invocations

# Audit I/O alignment and physical vs logical sector boundaries
lsblk -t -o NAME,ALIGN,MIN-IO,OPT-IO,PHY-SEC,LOG-SEC,ROTA,SCHED

# Audit Discard (TRIM) pass-through capabilities across layers
lsblk -D -o NAME,DISC-ALN,DISC-GRAN,DISC-MAX,DISC-ZERO

Terminal Output (Topology: lsblk -t)

NAME         ALIGN MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED
nvme0n1          0   4096      0    4096    4096    0 none
|-nvme0n1p1      0   4096      0    4096    4096    0 none
`-nvme0n1p2      0   4096      0    4096    4096    0 none
sda              0    512      0    4096     512    1 mq-deadline
|-sda1        1024    512      0    4096     512    1 mq-deadline
`-sda2           0    512      0    4096     512    1 mq-deadline

Terminal Output (Discard / TRIM: lsblk -D)

NAME            DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1                0        4M       2G         0
|-nvme0n1p1            0        4M       2G         0
`-nvme0n1p2            0        4M       2G         0
  `-cr_data            0        4M       2G         0
    `-vg-lv_app        0        0B       0B         0
sda                    0        0B       0B         0

Analytical Breakdown

1. Sector Alignment & The Read-Modify-Write Penalty

Examine sda: The physical sector size (PHY-SEC) is 4096 bytes (Advanced Format), while the logical sector size (LOG-SEC) is 512 bytes for legacy compatibility.

Partition sda1 reports an alignment offset (ALIGN) of 1024 bytes. Because writes cross physical 4K sector boundaries, the drive controller must read both sectors into cache, modify the bytes, and write them back—introducing massive I/O penalties. In contrast, nvme0n1 reports native 4K sectors (PHY-SEC=4096, LOG-SEC=4096) and ALIGN=0, ensuring optimal performance.

2. Discard / TRIM Topology Breakdown

The -D flag queries discard parameters documented in /sys/block/<dev>/queue/discard_*: * DISC-GRAN: The minimum allocation unit the drive controller can discard (e.g. 4MB). * DISC-MAX: The maximum size the controller can unmap in a single request (e.g. 2GB). * DISC-ZERO: Confirms whether discarded blocks return zeros on subsequent reads (0 = non-deterministic). * The Hidden Flaw: Notice that while physical drive nvme0n1 and crypto container cr_data support discard, the logical volume vg-lv_app reports DISC-GRAN=0B and DISC-MAX=0B. TRIM pass-through is broken at the LVM layer, meaning unused space is never reclaimed by the SSD controller.

What the Admin Does Next

Restore TRIM discard pass-through throughout the storage stack:

# 1. Enable discard support in the LVM configuration
sed -i 's/issue_discards = 0/issue_discards = 1/' /etc/lvm/lvm.conf

# 2. Reload the LUKS cryptographic container with discard support enabled
cryptsetup reload cr_data --allow-discards

# 3. Verify that lsblk now reports non-zero discard limits
lsblk -D

# 4. Trigger an on-demand filesystem TRIM sweep to reclaim unused flash blocks
fstrim -av

Under the Hood: The Kernel-to-Userspace Interface

To understand why lsblk is far more reliable than older utilities during a crisis, look at where it gets its information. Legacy tools often attempt direct, synchronous SCSI ioctl hardware queries. If a storage controller is malfunctioning or a SAN fiber path is degraded, those commands will hang indefinitely in an un-killable uninterruptible sleep state (D-state).

lsblk never issues blocking I/O calls to physical disks. Instead, it reads directly from kernel-maintained in-memory virtual interfaces.

1. Sysfs Virtual Hierarchy: lsblk queries /sys/class/block/ and /sys/dev/block/<major>:<minor>/. For every device, the kernel exposes cached queue limits, partition boundaries, and read-only attributes without touching physical platters.
2. Atomic Mount Tracking via Libmount: Mount points and filesystem usage metrics are gathered by parsing /proc/self/mountinfo via the libmount library, providing a lightning-fast snapshot of active mounts.
3. Metadata Cache via Libblkid & Udev: Filesystem labels, UUIDs, and partition UUIDs are retrieved from /run/udev/data/b<major>:<minor> via libblkid, reading pre-cached kernel discovery events rather than performing on-disk superblock reads.

What Can Go Wrong: Pitfalls, Hazards, and Recovery

Even a read-only diagnostic tool can deliver confusing results if you do not account for kernel edge cases.

Pitfall 1: Ghost Mappings and Stale Device-Mapper Nodes

When virtual machines, encrypted volumes, or software RAID arrays are torn down ungracefully, the kernel may retain device-mapper entries in /dev/mapper/ even after the physical backing storage is gone. lsblk will continue displaying these orphaned branches, leading engineers to believe a volume is healthy when it is actually stalled.

Diagnostic and Recovery Steps

# 1. List stale device-mapper nodes with unresolved dependencies
dmsetup info -c

# 2. Check for blocked or suspended device mapper states
dmsetup status

# 3. Safely remove the dangling device mapper link
dmsetup remove --force /dev/mapper/stale_orphan_volume

Pitfall 2: Multipath Redundancy Masking and Single-Path Contention

In enterprise Storage Area Networks (SANs) using Fibre Channel or iSCSI, a single storage volume is delivered over multiple redundant physical cables. If the multipathd daemon is stopped or misconfigured, lsblk will display each cable path as an independent physical disk rather than grouping them under a unified multipath device.

Recovery Action

Never mount raw /dev/sd* nodes on SAN-attached servers. Ensure multipathd is running and reload the mapping rules:

# Inspect multipath routing and path priorities
multipath -ll

# Force a reload of multipath device maps
multipath -r

Architectural Reference Matrix

Today's Takeaway

Mastering storage diagnostics begins with replacing outdated inspection habits with structured clarity. Open a terminal on your computer right now and run lsblk -e 7 -o NAME,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINT,ROTA,UUID,MODEL. In less than five seconds, you will filter out distracting Snap loop devices, catalog every physical and virtual drive, verify whether your filesystems are safely anchored to UUIDs, and confirm whether your databases are running on true solid-state hardware.