Re: Hard disks auto-spinning-down
On 10/29/19 12:59 AM, Mark Fletcher wrote: > On Mon, Oct 28, 2019 at 07:44:48PM +0200, Andrei POPESCU wrote: >> On Ma, 01 oct 19, 15:49:57, Alex Mestiashvili wrote: >>> >>> You may want to try hd-idle, it is not yet available in stable, but one >>> can install it from testing (it is not advisable in general, but the >>> divergence between buster and testing is not that big right now) >>> wget it from >>> http://ftp.de.debian.org/debian/pool/main/h/hd-idle/hd-idle_1.05+ds-2_amd64.deb >>> or any other Debian mirror and edit /etc/default/hd-idle in order to >>> start the daemon. >>> See man hd-idle for the details. >> >> One could also write to debian-backports, CC: the maintainer and ask >> nicely for a backport ;) It had been sitting in the backport queue at the moment of writing the email above as far as I remember. I just didn't know how long would it take until it is approved :) >> > Thanks for all this help, guys. Does anyone have any thoughts on why one > generation of an external disk cage wouldn't require this and just spun > down the disks automatically when idle, but the new one does require > incantations to do so? Bearing in mind that a Mac-using friend of mine > reports the same (new) model of cage does spin down the disks when > connected to a Mac without him having to have made any settings, so the > cage isn't against spinning down the disks or anything weird... There's > no reference at all to spinning down the disks in the cage's manual, but > there wasn't in the old generation's manual either. That's a complicated question, there are too many things which can influence a disk. See this answer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930796#42 It would be actually pretty cool if you could test the workarounds and post the results here. Best, Alex
Re: Hard disks auto-spinning-down
On Mon, Oct 28, 2019 at 07:44:48PM +0200, Andrei POPESCU wrote: > On Ma, 01 oct 19, 15:49:57, Alex Mestiashvili wrote: > > > > You may want to try hd-idle, it is not yet available in stable, but one > > can install it from testing (it is not advisable in general, but the > > divergence between buster and testing is not that big right now) > > wget it from > > http://ftp.de.debian.org/debian/pool/main/h/hd-idle/hd-idle_1.05+ds-2_amd64.deb > > or any other Debian mirror and edit /etc/default/hd-idle in order to > > start the daemon. > > See man hd-idle for the details. > > One could also write to debian-backports, CC: the maintainer and ask > nicely for a backport ;) > Thanks for all this help, guys. Does anyone have any thoughts on why one generation of an external disk cage wouldn't require this and just spun down the disks automatically when idle, but the new one does require incantations to do so? Bearing in mind that a Mac-using friend of mine reports the same (new) model of cage does spin down the disks when connected to a Mac without him having to have made any settings, so the cage isn't against spinning down the disks or anything weird... There's no reference at all to spinning down the disks in the cage's manual, but there wasn't in the old generation's manual either. Thanks Mark
Re: Hard disks auto-spinning-down
On Ma, 01 oct 19, 15:49:57, Alex Mestiashvili wrote: > > You may want to try hd-idle, it is not yet available in stable, but one > can install it from testing (it is not advisable in general, but the > divergence between buster and testing is not that big right now) > wget it from > http://ftp.de.debian.org/debian/pool/main/h/hd-idle/hd-idle_1.05+ds-2_amd64.deb > or any other Debian mirror and edit /etc/default/hd-idle in order to > start the daemon. > See man hd-idle for the details. One could also write to debian-backports, CC: the maintainer and ask nicely for a backport ;) Kind regards,f Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Hard disks auto-spinning-down
On 9/29/19 1:30 PM, Mark Fletcher wrote: > Since a fresh install of buster, an external USB3 hard disk cage from > Terramaster that I own is not automatically spinning down the disks in > it when they go unused for a time. > > I used a previous generation of the cage with Stretch previously, it > spun down the disks when they were not in use (actually a little too > quickly for my taste) reliably and I don't recall doing anything to make > that happen. > > Any thoughts on where I might look to find settings that can be tweaked > to make it spin down when idle? A friend of mine uses the same cage with > a Mac and says it spins down when not in use, so I feel like I should be > able to do it somehow. > > The only thing I can think of that I've tweaked since installing buster > is to disable suspend, as I didn't want the whole computer suspending > when I was away for a bit, as this computer does a lot of background > processing. I wonder if I overdid that and disabled something I should > have left enabled? The solution to that problem involved disabling a > couple of systemd targets. > > I just re-googled that problem because I couldn't remember what targets > I disabled -- and now I see on the wiki that they are sleep.target > hibernate.target suspend.target and hybrid-sleep.target. The wiki says > to do "systemctl mask" on those targets but I suspect I followed someone > else's advice and did "systemctl disable" on those targets. > > Any link to this problem? Otherwise where should I look? > > Thanks > > Mark > You may want to try hd-idle, it is not yet available in stable, but one can install it from testing (it is not advisable in general, but the divergence between buster and testing is not that big right now) wget it from http://ftp.de.debian.org/debian/pool/main/h/hd-idle/hd-idle_1.05+ds-2_amd64.deb or any other Debian mirror and edit /etc/default/hd-idle in order to start the daemon. See man hd-idle for the details. Best, Alex
Re: Hard disks auto-spinning-down
> logger "Setting spindown on disk drive: $DISK_DEV" > sdparm --flexible -6 --set SCT=4000 $DISK_DEV > sdparm --flexible -6 --set STANDBY=1 $DISK_DEV I found sdparm inscrutable so far so I'm really curious how you came up with the above incantation (`sdparm -al /dev/sdb` doesn't list any SCT nor STANDBY field for my WD20NPVT-00Z disk, for example). Stefan
Re: Hard disks auto-spinning-down
On Mon, Sep 30, 2019 at 01:41:37AM -0700, B wrote: > > > On 9/29/19 4:30 AM, Mark Fletcher wrote: > > Any thoughts on where I might look to find settings that can be tweaked > > to make it spin down when idle? > > > See sdparm and hdparm tools. hdparm is probably the wrong tool because it's > for internal drives connected to IDE/ATA/SATA busses. The reason sdparm > works for USB drives is because of SCSI-over-USB emulation. See man page for > more info. > > The best way to do it is with a udev rule that will run some commands when > the USB device gets plugged in. Otherwise the device resets it's config each > time you plug it in. > Thanks a lot for the suggestions and the details. I will try this later. Much appreciated. Do you (or anyone else) have any thoughts on why this is necessary in Buster but wasn't in Stretch? Or is it more likely to be that the new cage isn't triggering a udev rule the old one was or something? Thanks again for your help Mark
Re: Hard disks auto-spinning-down
On 9/29/19 4:30 AM, Mark Fletcher wrote:
Any thoughts on where I might look to find settings that can be tweaked
to make it spin down when idle?
See sdparm and hdparm tools. hdparm is probably the wrong tool because
it's for internal drives connected to IDE/ATA/SATA busses. The reason
sdparm works for USB drives is because of SCSI-over-USB emulation. See
man page for more info.
The best way to do it is with a udev rule that will run some commands
when the USB device gets plugged in. Otherwise the device resets it's
config each time you plug it in.
Here's an actual example from my system:
-->cat /etc/udev/rules.d/86-Seagate-4TB-usb-disk-sleep.rules
ACTION=="add", SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="NA8E4BKU",
RUN+="/usr/local/sbin/udev-set-usb-hdd-spindown.sh"
-->cat /usr/local/sbin/udev-set-usb-hdd-spindown.sh
#!/bin/bash
PATH="/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin"
# Seagate USB3 4TB disk drive.
DISK_DEV=/dev/disk/by-id/usb-Seagate_Expansion_Desk_NA8E4BKU-0:0
if [[ -e "$DISK_DEV" ]] ; then
logger "Setting spindown on disk drive: $DISK_DEV"
sdparm --flexible -6 --set SCT=4000 $DISK_DEV
sdparm --flexible -6 --set STANDBY=1 $DISK_DEV
fi ; unset DISK_DEV
There's a convoluted reason why I call the script instead of just
running the commands in the udev rule itself. If possible I'd tell you
to just use a udev rule and skip the external script. Do what's right
for you.
There might be some GUI tool out there that will do this for you but
that's how I do it. See man pages and google for more hints. Good luck.
Hard disks auto-spinning-down
Since a fresh install of buster, an external USB3 hard disk cage from Terramaster that I own is not automatically spinning down the disks in it when they go unused for a time. I used a previous generation of the cage with Stretch previously, it spun down the disks when they were not in use (actually a little too quickly for my taste) reliably and I don't recall doing anything to make that happen. Any thoughts on where I might look to find settings that can be tweaked to make it spin down when idle? A friend of mine uses the same cage with a Mac and says it spins down when not in use, so I feel like I should be able to do it somehow. The only thing I can think of that I've tweaked since installing buster is to disable suspend, as I didn't want the whole computer suspending when I was away for a bit, as this computer does a lot of background processing. I wonder if I overdid that and disabled something I should have left enabled? The solution to that problem involved disabling a couple of systemd targets. I just re-googled that problem because I couldn't remember what targets I disabled -- and now I see on the wiki that they are sleep.target hibernate.target suspend.target and hybrid-sleep.target. The wiki says to do "systemctl mask" on those targets but I suspect I followed someone else's advice and did "systemctl disable" on those targets. Any link to this problem? Otherwise where should I look? Thanks Mark
