6

With Fedora 27, when disconnecting an external USB disk drive the journal records lines like these:

May 07 22:29:11 usb 2-3.1: USB disconnect, device number 23
May 07 22:29:11 sd 3:0:0:0: [sdb] Synchronizing SCSI cache
May 07 22:29:11 sd 3:0:0:0: [sdb] Synchronize Cache(10) failed:
                            Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

What is one supposed to do about this?

why does the system/kernel tries to synchronize the cache after the drive is already disconnected?

Is it possible to gracefully shutdown the USB disk before the disconnect? For example with a command that issues the Synchronize-Cache command and then spins down the drive.

This would perhaps also reduce mechanical stress on the drive as the sudden power-loss with spinning disk isn't necessarily optimal.

Edit: An eject /dev/sdb is ineffective, i.e. the above kernel messages still show up on device unplug and the disk keeps spinning. Instead the eject command yields these kernel log messages:

May 18 17:26:06  ldm_validate_partition_table(): Disk read failed.
May 18 17:26:06  Dev sdb: unable to read RDB block 0
May 18 17:26:06   sdb: unable to read partition table
May 18 17:26:06  ldm_validate_partition_table(): Disk read failed.
May 18 17:26:06  Dev sdb: unable to read RDB block 0
May 18 17:26:06   sdb: unable to read partition table

Edit: Powering the disk down with udisksctl power-off --block-device /dev/sdb does work:

May 19 08:08:21  udisksd[9447]: Successfully sent SCSI command SYNCHRONIZE CACHE 
                                to /dev/sdb
May 19 08:08:21  udisksd[9447]: Successfully sent SCSI command START STOP UNIT
                                to /dev/sdb
May 19 08:08:21  kernel: sd 3:0:0:0: [sdb] Synchronizing SCSI cache
May 19 08:08:21  udisksd[9447]: Powered off /dev/sdb - successfully wrote
         to sysfs path /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/remove
May 19 08:08:21  kernel: usb 2-3.1: USB disconnect, device number 60

And indeed, the disk then powers down.

7
  • Oh noes, they messed up the kernel again. File a bug.
    – ajeh
    May 18, 2018 at 13:58
  • 2
    Using the eject command should do the trick. It's not just for optical drives, but for any removable media.
    – Tim Kennedy
    May 18, 2018 at 14:17
  • @TimKennedy, a eject /dev/sdb is ineffective, cf. the output in the updated question.
    – maxschlepzig
    May 18, 2018 at 15:29
  • /dev/sdb is the device as a whole, not necessarily the filesystem. The filesystem is probably /dev/sdb1 or something. lsblk can identify the filesystems for you. Then you'd need to eject /dev/sdb1 (or whatever partition is your filesystem)
    – Tim Kennedy
    May 18, 2018 at 16:00
  • @TimKennedy, actually the disk doesn't have any partitions; the complete device is luks-encrypted; and inside the luks-device there is just one big filesystem and no partition table
    – maxschlepzig
    May 18, 2018 at 16:03

1 Answer 1

Reset to default
4

Use udisksctl to power off the drive:

   power-off
       Arranges for the drive to be safely removed and powered off. On the OS side this includes ensuring that
       no process is using the drive, then requesting that in-flight buffers and caches are committed to stable
       storage. The exact steps for powering off the drive depends on the drive itself and the interconnect
       used. For drives connected through USB, the effect is that the USB device will be deconfigured followed
       by disabling the upstream hub port it is connected to.

so e.g.

udisksctl power-off --block-device /dev/sdb

You can run the command as a regular user, no need for root access.
If you prefer a gui, gnome disks has a button to "power off this disk".

1
  • This works, cf. my updated answer. When the udisks2 isn't running, I assume that the sequence sdparm --command=sync /dev/sdb then sdparm --command=stop /dev/sdb or sg_start --stop /dev/sdb and finally echo 1 > /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/remove yields the same results. Perhaps the sync is superfluous as the last step also triggers 'Synchronizing SCSI cache' message. Similarly, the stop command doesn't really stop the device, while the last step does. Thus, perhaps the echoing to '/sys/devices/.../remove` is sufficient.
    – maxschlepzig
    May 19, 2018 at 6:53

You must log in to answer this question.

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