Usage Scenario:
System running on a USB3.0 mobile HDD docker or attached with a external hard drive for more storage.
Issue:
My Erp is ON (Powerdown the USB 5V VBUS after shutdown----motherboard’s function)
External usb scsi HDDs will NOT park their heads to parking lot keeping spinning.
Unmount.target is not enough for usb scsi subsystem.
It powerdown my HDD brutally.
At least It not work for my Asmedia 1153e chip HDD case.
My expect:
Add the udev policy as default or more graceful solutions to solve the issue.
the most graceful way to do this is:
My difficulties(LONG story):
It’s really frustrating and disappointing when I realize my “HDD Emergency Power-Off Retract Count” in SMART INfo have increased to nearly thousands.
Just because there is no hint that "sudo poweroff \ systemctl poweroff \ reboot \ init 0\ init 6 " will NOT properly power off my USB HDD, it only unmount partitions, then it just hard power off.
I tried searching the internet then they all answered with udiskctl, hdparm, udev script, sdparm, manual unmout action in dophin(KDE User), from here\ArchWiki\reddit\google\askubuntu\raspberrypi_forum… just to name a few.
And they all too hard and do not work for me.
It just too hard for me to understand how systemd works, and how to write bash script.
I just want my HDD power off before shutdown safely like Windows or MacOS.
Then I finally notice a post on
bugzilla;kernel;org/show_bug.cgi?id=205107
and followed the comment 21 , then it works.
It takes too long to solve this tiny problem…
THANKS in advance if it is a default in manjaro ( I don’t know other distros have this ).
And if there is better solution please let me know, Appreciated!
The udisks command is most likely what you are looking for.
While sudo unmount /dev/sdXY will work, udisks can do this without root level (sudo) permissions.
If you have a drive /dev/sdXY, mounted, where X is a letter representing your usb disk and Y is the partition number (usually 1), you can use the following commands to safely remove the drive:
Really Appreciated @Mirdarthos [Mirdarthos]
, but udisk2 util udiskctl need to be execution manually or add it as systemd script to autorun.
And seems not work when systemd reach unmount.target for my case for unknown reasons.
And the hdparm sdparm also need a script to do this.
I think these solutions are not graceful and maybe not reliable ,
for those users have mutiple usb scsi HDD ,they need a bash(shell) script to recurse all /dev/sd* to execute the script ,and tracing the execution result is not easy.
The solution above
AFAIK nothing special is needed on shutdown, since it’s done automagically.
If you want it do-able manually, then you can do it in a short script which you run instead of remove the device manually, but that is way. way. WAY above my paygrade.
That’s right,
It should do it automagically, but the result is not,
the post on bugzilla for kenel org show the detailed issue
bugzilla;kernel;org/show_bug.cgi?id=205107
(i can’t post URL,use ; to repace .)
I do not know why linux kernel not do this automagically like windows and macos
Doesn’t modern disk implement autopark for the same reason?
I have a Seagate 2TB rotational 5400RPM and I have two choices with the file manager
unmount
safely remove
The first unmount - but do not power down the device
The second unmount and power down the disk - completely removing it from the system.
If I don’t unmount the device but instead I shut down the system the device unmount but stays powered until the hardware is powered off.
I think you point to the cause by the mention of your HDD case - perhaps the case is causing this?
The usage of an external case and disk powered over USB is quite common.
So here is an idea of what is going on.
When you use the same disk inside your system connected to the mainboard using sata or similar your disk will receive a command to park heads prior to power down.
The same signal may be send to the USB connected device but the case interface may not pass on the signal.
Yes ,the HDD will auto park after a period of time,
But I have Erp on(Powerdown the USB 5V VBUS after shutdown----motherboard’s function)
The mother board will turnoff 5v vbus for eco (I don’t want my perpheral lights on).
for USB SCSI DISK shutdown seems it not sending SCSI spin down command unless "
/sys/…/manage_start_stop" is set to 1,
It just unmount,
only SCSI read/write USB packets is transfered when systemd handle unmount.target.And the disk is not prepared to be turnoff.
The asmedia 1153e and other WD passport is the issue indeed ,
but the implement of linux driver to handle USB SCSI DISK shutdown spindown is not default.
It is default for windows, every reboot shutdown hibernate or sleep , it spin down the disks before system call acpi to shut the mother board vbus.
the linux need to be done manully.
That’s right. It’s an old issue.
I’m not familar with linux kernel dev,
Maybe manually turn off the usb disk is right solution and it’s the creed for geek linux user.
But it will be really disappointing when I found my usb HDD broken because of this.
But i do need set it to be 1 to make it work.
I have not figured out why.
I cat my usb scsi device as 0 by default:
cat /sys/devices/pci0000:00/0000:00:08.1/0000:2a:00.3/usb4/4-1/4-1:1.0/host10/target10:0:0/10:0:0:0/scsi_disk/10:0:0:0/manage_start_stop
0
Maybe linux kernel do not handle USB SCSI Device like other native ones
After some digging into the code.
I probably find the reason why the usb-storage, uas, and some sas driver do not handle this.
Driver need to operate generic devices, maybe the chip itself handling spindown must be the proper way. Sadly, chip manufactures often have their unique quirks.
Such as this Asmedia chip asm1135.
But if Chips do not handle this as a routine, then the driver should take responsibility to tackle with it.
I found the commit Damien Le Moal did last year for Firewire. It clearly show this type of device configuration need to be done within low level driver.
Other driver also need similar change to adapt Damien Le Moal changed last year.
I did made some mod in kernel for my own use. But I have never post a patch to kernel mailing list, I think it is not a easy thing to start.
So if someone is experienced and willing to make a patch for upstream kernel driver, I will be appreciated!