You are not logged in.
Pages: 1
I have a couple of external HDDs from LaCie (LaCie Rugged FW USB3). Once they are connected, they will keep on running until either being physically disconnected or the system's power being turned off.
It is (sometimes) possible to turn them off with hdparm and the drive is not spinning anymore, but the hdparm command still lists it as active/idle. Strange behavior.
Now, I'm not so much concerned about the drive's being turned on while working on the computer. But it should be turned off when I send the machine into standby. The internal HDD gets successfully turned off at such times without any manual intervention necessary.
Any ideas?
Offline
It depends a lot on the bridge chip that the enclosure uses, from personal experience I'd say some are well behaved and mostly stay out of the way, but others have a will of their own and will override what you tell the enclosure/disk to do and revert things to a preprogrammed state.
The only choice you have there is using hdparm to send the disk into standby, suspend the machine, and hope the usb vbus is not cut and restored again when going into suspend or the disk/enclosure not is queried in a way that wakes up the disk. If the bridge chip overrides that and wants the disk to be spinning I guess you may be out of luck. The funny thing is that seems to be an odd behavior as most external disks have to some degree a tendency to spin down regardless of what you say.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
@R00KIE:
Well, it's not the first time that I am experiencing problems with products from LaCie. About half a year ago, I ran into this issue: https://bbs.archlinux.org/viewtopic.php?id=211523
It was actually you who gave me advice to solve it. Thanks again for that. And just recently, a USB flash drive from the same manufacturer has quit working altogether and is now merely recognized as NAND memory.
Well, no more LaCie's in the future I guess... At least not for me.
Well, now it seems like to be an issue with the controller because the internal HDD (SATA) has always properly shut down when I sent the system into standby. Even before hdparm was even installed.
I have installed the gnome-disk-utility, hdparm and sdparm (just in case) and if I run the GNOME disk utility, I am able to send the HDD into standby (manually). I believe it just executes a
hdparm -y /dev/sdX
If I however try to set the time after which the drive is supposed to go into standby, it is completely ignored by the system and the drive keeps spinning until it gets (physically) disconnected.
Which leads me to believe that it is accepting hdparm commands but doesn't report back its current state, e.g. it always reports to be active/idle, even if it is in fact turned off.
[UPDATE 09/25/2016 14:00 JST]
I can send the disk into standby using
sudo hdparm -y /dev/sdX
, sending it to sleep using
sudo hdparm -Y /dev/sdX
seems to have no effect on the sound/vibration of the drive.
In both cases a
sudo hdparm -C /dev/sdX
returns that the drive was active/idle (which is not true if I send it into standby)
@R00KIE: Yes, I can send the disk into standby and then the whole system. The disk will stay in this state until the system is resumed.
hdparm -I for the drive reports back the following information
ATA device, with non-removable media
Model Number: LaCie Rugged USB3-FW
Serial Number: S2ZUJ9AD201845
Firmware Revision: 31101081
Standards:
Used: ATA/ATAPI-6 published, ANSI INCITS 361-2002
Supported: 6 5 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 15151 KBytes (type=DualPortCache)
Capabilities:
LBA, IORDY(cannot be disabled)
Standby timer values: spec'd by Vendor, with device specific minimum
R/W multiple sector transfer: Max = 1 Current = 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
* Power Management feature set
* Write cache
* 48-bit Address feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART self-test
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
Checksum: correct
"Standby timer values: spec'd by Vendor, with device specific minimum" <-- Could this be the culprit?
Last edited by i716 (2016-09-25 05:18:39)
Offline
That bridge chip might be the stubborn kind, as it doesn't even let you identify the disk inside the enclosure. I have never come across a controller that did that, what seems to be the norm when it comes to enclosures from known brands is that setting the idle standby timer seems to do nothing, either the controller filters the request and returns success or it will (periodically?) overwrite the setting and use a vendor default.
I have had the opposite problem you are having, trying to run a smart self-test on a disk inside an enclosure that will put the disk to sleep after some time will abort the test and no matter what I did I was not able to keep the disk awake.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1