How to Hot-Swap SATA Drives in Linux Using Sysfs

This article provides an overview of how the Linux operating system detects and manages hot-swapped SATA drives using the sysfs virtual filesystem. When hardware is plugged or unplugged from an active system, the Linux kernel relies on its SCSI subsystem abstraction and AHCI drivers to dynamically add or drop storage devices. By interacting directly with specific control files exposed in /sys, system administrators can safely prepare disks for physical removal and instruct the kernel to scan for newly inserted storage devices without rebooting.

The Architecture Behind Linux SATA Management

In Linux, SATA devices are abstracted and handled by the libata driver layer, which routes them through the SCSI subsystem. Because of this, SATA drives appear as SCSI block devices (e.g., /dev/sda, /dev/sdb), and their physical interfaces (ports) are represented under /sys/class/scsi_host/.

Hot-swapping requires two conditions at the hardware level: the motherboard controller must support AHCI mode, and the SATA power and data connectors must support hot-plugging. When these criteria are met, the kernel can register physical link state changes automatically in many modern systems. However, in environments where automatic hardware interrupts are not triggered or reliable, software-level control via sysfs provides deterministic control over device initialization and teardown.

Safely Removing a SATA Drive

To remove a SATA drive without causing data corruption or kernel panics, the operating system must cease all read and write operations and unregister the disk from the active device tree.

  1. Unmount Filesystems and Stop Services: Unmount any active partitions on the device using umount and stop any software RAID or LVM arrays utilizing the drive.
  2. Flush Hardware Caches: Run sync to ensure any cached data waiting in memory is committed to the physical platters or flash cells.
  3. Delete the Device from the Subsystem: Issue a removal command to the device's specific delete entry in sysfs:
echo 1 > /sys/block/sdX/device/delete

(Replace sdX with the designated target device, such as sdb.)

Writing 1 to this file instructs the SCSI mid-layer to cleanly detach the device. The kernel flushes any remaining device queues, shuts down the read/write channels, removes the /dev/sdX entries, and powers down the drive port if supported. Once this command finishes execution, the drive can be safely disconnected physically.

Detecting a Newly Inserted SATA Drive

When a new SATA drive is plugged into a running machine, the kernel might not automatically generate a new device node if the controller does not broadcast an interrupt event. In this case, the administrator can force a manual scan of the SCSI host adapter.

  1. Identify the SCSI Host: Determine which SCSI host adapter controls the target SATA port. You can view all available hosts by listing the directory:
ls /sys/class/scsi_host/

This typically returns entries such as host0, host1, host2, etc.

  1. Trigger the Rescan: Write the SCSI scan parameters to the scan interface of the appropriate host controller:
echo "- - -" > /sys/class/scsi_host/hostX/scan

(Replace hostX with the target host interface, such as host0, or loop through all available hosts.)

The three dashes (- - -) act as wildcards representing:

Using wildcards instructs the kernel's SCSI scanning routine to query every channel, target, and LUN on that host.

Kernel Execution Flow During Rescan

When the string "- - -" is echoed into the scan node:

  1. The kernel invokes the scsi_scan_host() routine in the SCSI mid-layer.
  2. The SATA driver (such as ahci) queries the physical PHY layer on the SATA ports associated with that controller to negotiate link speed and establish communication.
  3. The kernel sends standard SCSI inquiry commands to the drive to gather metadata (vendor, model, serial number, geometry, and capacity).
  4. Upon receiving valid responses, the SCSI subsystem assigns a new target identity and creates the corresponding block device files.
  5. The udev daemon captures the hardware addition event, generating the symbolic links in /dev/disk/by-id/, /dev/disk/by-uuid/, and the main node /dev/sdX.

You can verify successful detection immediately after running the rescan command by inspecting the kernel message buffer with dmesg | tail -n 20 or by running lsblk.