I sometimes need to plug a disk into a disk bay. At other times, I have the very weird setup of connecting a SSD using a SATA-eSATA cable on my laptop while pulling power from a desktop.

How can I safely remove the SATA disk from the system? This Phoronix forum thread has some suggestions:

justsumdood wrote:

An(noymous)droid wrote:
What then do you do on the software side before unplugging? Is it a simple "umount /dev/sd"[drive letter]? after unmounting the device, to "power off" (or sleep) the unit:

hdparm -Y /dev/sdX

(where X represents the device you wish to power off. for example: /dev/sdb)

this will power the drive down allowing for it's removal w/o risk of voltage surge.

Does this mean that the disk caches are properly flushed and powered off thereafter?

Another suggestion from the same thread:

chithanh wrote:
All SATA and eSATA hardware is physically able to be hotplugged (ie. not damaged if you insert/pull the plug).

How the chipset and driver handles this is another question. Some driver/chipset combinations do not properly handle hotplugging and need a warmplug command such as the following one:

echo 0 - 0 > /sys/class/scsi_host/hostX/scan

Replace X with the appropriate number for your SATA/eSATA port.

I doubt whether is the correct way to do so, but I cannot find some proof against it either.

So, what is the correct way to remove an attached disk from a system? Assume that I have already unmounted every partition on the disk and ran sync. Please point to some official documentation if possible, I could not find anything in the Linux documentation tree, nor the Linux ATA wiki.

7 Answers 7

  1. Unmount any filesystems on the disk. (umount ...)
  2. Deactivate any LVM groups. (vgchange -an)
  3. Make sure nothing is using the disk for anything.
    • You Could unplug the HDD here, but it is recommended to also do the last two steps
  4. Spin the HDD down. (irrelevant for SSD's) (sudo hdparm -Y /dev/(whatever))
  5. Tell the system, that we are unplugging the HDD, so it can prepare itself. (echo 1 | sudo tee /sys/block/(whatever)/device/delete)

If you want to be extra cautious, do echo 1 | sudo tee /sys/block/(whatever)/device/delete first. That'll unregister the device from the kernel, so you know nothing's using it when you unplug it. When I do that with a drive in an eSATA enclosure, I can hear the drive's heads park themselves, so the kernel apparently tells the drive to prepare for power-down.

If you're using an AHCI controller, it should cope with devices being unplugged. If you're using some other sort of SATA controller, the driver might be confused by hotplugging.

In my experience, SATA hotplugging (with AHCI) works pretty well in Linux. I've unplugged an optical drive, plugged in a hard drive, scanned it for errors, made a filesystem and copied data to it, unmounted and unplugged it, plugged in a differerent DVD drive, and burned a disc, all with the machine up and running.

  • I had a need to unplug a HDD which I wanted to erase completely. After pulling the disk out of the bay, /dev/sdXY still showed up. Writing 1 to delete made it disappear and I could hear the disk spinning down. Just hdparm -Y was not enough because the /dev/ entries would still exist. Thanks!
    – Lekensteyn
    Commented Aug 9, 2012 at 9:25
  • 25
    I strongly advice to always issue the echo 1 > /sys/block/(whatever)/device/delete command because the drive will park the heads, fully stop the disk and disable power on the bus. If a non-parked head touches a spinning plate the drive can be permanently destroyed.
    – drumfire
    Commented Feb 12, 2014 at 21:21
  • 3
    Also - if smartd happens to be running, it's a good idea to issue a SIGHUP to the process so that it reloads the drive info. Especially important if you're replacing drives because smartd will reload the info for that drive and all others.
    – drumfire
    Commented Feb 12, 2014 at 21:23
  • 4
    Appears to me that hdparm -Y and the trick with /sys/block/sdX/device/delete are mutually exclusive. Because if you spin the drive down using hdparm, the "block layer delete" will probably have to spin it up anyway in order to flush the cache and bid it farewell - and then spin it down anyway. And, once you do the "block layer delete", the device node will vanish from /dev/, so you have nothing to run hdparm on anymore. So I agree with @drumfire - just do the "block layer delete". Tested right now, works like a charm. Upvoting this answer and the topic :-)
    – frr
    Commented Nov 11, 2021 at 17:51

what about eject /dev/sdX? On my setup, this commands umounts, syncs and powers down the drive.

  • 6
    I tried this with a disk connected over eSATA but the command failed with "not hotpluggable" or something.
    – Lekensteyn
    Commented Aug 30, 2013 at 9:29
  • 2
    Afaik eject plugs out the pluggable disk and not the device. It depends on that the block device driver supports the ioctl() operation used by the eject tool. Esata hard disk drives don't support it, but optical devices, floppies and probably flash drives, yes.
    – peterh
    Commented Jul 31, 2015 at 4:11

Those two sections are for different things.

The first is for unplugging. The second is for plugging.

For unplugging, the OS will sync the data during the unmount operation. Thus, if the disk is unmounted (assuming you in fact do have full hardware support) you can power off the disk then unplug it without risk of data loss or corruption.

For plugging, the device should be automatically recognized. If not, you can execute that command to trigger a bus scan. Once the device is recognized you can mount it.

And let me caveat this by saying I've only ever done this sort of thing with USB drives.

  • Thanks for your answer, but I am still not convinced what the correct action would be. SSDs have a "Unsafe Shutdown Count" S.M.A.R.T. field, just unplugging it without doing anything does not sound safe to me.
    – Lekensteyn
    Commented Jul 18, 2012 at 21:58
  • 3
    If it helps, I routinely hot-plug and hot-unplug SATA hard drives as part of my job, with no more than making sure it's unmounted first, and I've never run into a problem. That's anecdotal, so don't take it as gospel, but it's at least some evidence that it's likely safe. In any case, I'd consider it a kernel bug if the OS doesn't ensure that the data is fully written at the end of an unmount operation, especially in a hotplug world.
    – Jander
    Commented Jul 19, 2012 at 0:24
  • 2
    @Lekensteyn, the hdparm -Y will take care of that. That is basically what the system does every time you suspend or shutdown.
    – psusi
    Commented Jul 19, 2012 at 13:16

I have a pair of scripts that build upon the answer by Wyzard. The first, scsi-drop, is to safely detach a single disk:


if test -h "$1"
    disk=$(chase "$1")

if test -b "$disk"
    echo 1 >/sys/block/$(basename "$disk")/device/delete
    echo "$0: not a block device: $1" >&2
    exit 1

Its main benefit is that you can pass it a symlink, such as found in /dev/disk/by-id/ and it will resolve that to the real device. It does require chase to be installed; you might be able to get the same result using readlink -e.

The second script, scsi-rescan, is used after hotplugging a new device:


exec tee /sys/class/scsi_host/host*/scan <<<'- - -' >/dev/null

This makes all adapters re-scan for devices. It was the only way I managed to get the new capacity and partition table to be read.


To disconnect and power off a USB device in Linux (2023 edition):

  1. Get the list of volumes: dmsetup ls --tree

  2. Remove volume: dmsetup remove <volume_name>, ie dmsetup remove fedora_host-root

  3. Get list of devices: lsblk -f

  4. Power off device (by block device or by object path):

    udisksctl power-off -b <device_name>, ie: udisksctl power-off -b /dev/sda


Actually, SATA drives automatically park the heads when power is lost. Pulling the drive while it is still spinning, should not result in issues. However, spinning disks are prone to dings if bumped. You can hear this when you have flaky power or solar flares.

Most damage is usually caused by, unflushed cache and uncommitted writes in buffers etc ... This is why you MUST unmount a drive, before removing it. The SCSI command is just good measure and works to the same end.


I wrote a script for this using umount and hdparm suspend. Feel free to edit the script and use at your own risk. The script is interactive or can be run with options.


  • Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. Commented Apr 25, 2023 at 11:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .