Gracefully shutting down USB disk drives before disconnect
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
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.
linux hard-disk usb-drive
asked May 18 at 13:41
maxschlepzig
31.8k29134202
 |Â
show 2 more comments
up vote
4
down vote
favorite
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.
linux hard-disk usb-drive
asked May 18 at 13:41
maxschlepzig
31.8k29134202
Oh noes, they messed up the kernel again. File a bug.
– ajeh
May 18 at 13:58
2
Using theejectcommand should do the trick. It's not just for optical drives, but for any removable media.
– Tim Kennedy
May 18 at 14:17
@TimKennedy, aeject /dev/sdbis ineffective, cf. the output in the updated question.
– maxschlepzig
May 18 at 15:29
/dev/sdbis the device as a whole, not necessarily the filesystem. The filesystem is probably/dev/sdb1or something.lsblkcan identify the filesystems for you. Then you'd need toeject /dev/sdb1(or whatever partition is your filesystem)
– Tim Kennedy
May 18 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 at 16:03
 |Â
show 2 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
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.
linux hard-disk usb-drive
asked May 18 at 13:41
maxschlepzig
31.8k29134202
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.
linux hard-disk usb-drive
asked May 18 at 13:41
maxschlepzig
31.8k29134202
edited May 19 at 6:47
asked May 18 at 13:41
maxschlepzig
31.8k29134202
asked May 18 at 13:41
maxschlepzig
31.8k29134202
asked May 18 at 13:41
maxschlepzig
31.8k29134202
31.8k29134202
Oh noes, they messed up the kernel again. File a bug.
– ajeh
May 18 at 13:58
2
Using theejectcommand should do the trick. It's not just for optical drives, but for any removable media.
– Tim Kennedy
May 18 at 14:17
@TimKennedy, aeject /dev/sdbis ineffective, cf. the output in the updated question.
– maxschlepzig
May 18 at 15:29
/dev/sdbis the device as a whole, not necessarily the filesystem. The filesystem is probably/dev/sdb1or something.lsblkcan identify the filesystems for you. Then you'd need toeject /dev/sdb1(or whatever partition is your filesystem)
– Tim Kennedy
May 18 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 at 16:03
 |Â
show 2 more comments
Oh noes, they messed up the kernel again. File a bug.
– ajeh
May 18 at 13:58
2
Using theejectcommand should do the trick. It's not just for optical drives, but for any removable media.
– Tim Kennedy
May 18 at 14:17
@TimKennedy, aeject /dev/sdbis ineffective, cf. the output in the updated question.
– maxschlepzig
May 18 at 15:29
/dev/sdbis the device as a whole, not necessarily the filesystem. The filesystem is probably/dev/sdb1or something.lsblkcan identify the filesystems for you. Then you'd need toeject /dev/sdb1(or whatever partition is your filesystem)
– Tim Kennedy
May 18 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 at 16:03
Oh noes, they messed up the kernel again. File a bug.
– ajeh
May 18 at 13:58
Oh noes, they messed up the kernel again. File a bug.
– ajeh
May 18 at 13:58
2
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 at 14:17
Using the
eject command should do the trick. It's not just for optical drives, but for any removable media.– Tim Kennedy
May 18 at 14:17
@TimKennedy, a
eject /dev/sdb is ineffective, cf. the output in the updated question.– maxschlepzig
May 18 at 15:29
@TimKennedy, a
eject /dev/sdb is ineffective, cf. the output in the updated question.– maxschlepzig
May 18 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 at 16:00
/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 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 at 16:03
@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 at 16:03
 |Â
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
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".
answered May 19 at 0:05
don_crissti
46.2k15121151
This works, cf. my updated answer. When theudisks2isn't running, I assume that the sequencesdparm --command=sync /dev/sdbthensdparm --command=stop /dev/sdborsg_start --stop /dev/sdband finallyecho 1 > /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/removeyields 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 at 6:53
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
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".
answered May 19 at 0:05
don_crissti
46.2k15121151
This works, cf. my updated answer. When theudisks2isn't running, I assume that the sequencesdparm --command=sync /dev/sdbthensdparm --command=stop /dev/sdborsg_start --stop /dev/sdband finallyecho 1 > /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/removeyields 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 at 6:53
add a comment |Â
up vote
2
down vote
accepted
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".
answered May 19 at 0:05
don_crissti
46.2k15121151
This works, cf. my updated answer. When theudisks2isn't running, I assume that the sequencesdparm --command=sync /dev/sdbthensdparm --command=stop /dev/sdborsg_start --stop /dev/sdband finallyecho 1 > /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/removeyields 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 at 6:53
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
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".
answered May 19 at 0:05
don_crissti
46.2k15121151
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".
answered May 19 at 0:05
don_crissti
46.2k15121151
answered May 19 at 0:05
don_crissti
46.2k15121151
answered May 19 at 0:05
don_crissti
46.2k15121151
answered May 19 at 0:05
don_crissti
46.2k15121151
46.2k15121151
This works, cf. my updated answer. When theudisks2isn't running, I assume that the sequencesdparm --command=sync /dev/sdbthensdparm --command=stop /dev/sdborsg_start --stop /dev/sdband finallyecho 1 > /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/removeyields 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 at 6:53
add a comment |Â
This works, cf. my updated answer. When theudisks2isn't running, I assume that the sequencesdparm --command=sync /dev/sdbthensdparm --command=stop /dev/sdborsg_start --stop /dev/sdband finallyecho 1 > /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/removeyields 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 at 6:53
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 at 6:53
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 at 6:53
add a comment |Â
Â
draft saved
draft discarded
Â
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f444611%2fgracefully-shutting-down-usb-disk-drives-before-disconnect%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Oh noes, they messed up the kernel again. File a bug.
– ajeh
May 18 at 13:58
2
Using the
ejectcommand should do the trick. It's not just for optical drives, but for any removable media.– Tim Kennedy
May 18 at 14:17
@TimKennedy, a
eject /dev/sdbis ineffective, cf. the output in the updated question.– maxschlepzig
May 18 at 15:29
/dev/sdbis the device as a whole, not necessarily the filesystem. The filesystem is probably/dev/sdb1or something.lsblkcan identify the filesystems for you. Then you'd need toeject /dev/sdb1(or whatever partition is your filesystem)– Tim Kennedy
May 18 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 at 16:03