drive power down interface #885
Comments
|
Four thoughts about that: 1. Per-pool timeout instead of per-disk Setting timeout for each drive might lead to confusion as the user has to check which drives belong to the same pool. Maybe it should be better set per pool (BTRFS filesystem)? 2. Non-rotational devices 3. Don't forget, but take care with 4. Processes might spin up disks again
Currently, I configure spindown times with this systemd startup script: #!/bin/sh
# list all disks
lsblk -p -i -o KNAME,TYPE,SIZE,MODEL | while read dev type size model; do
# only process disks (skip partitions etc.)
test $type != "disk" && continue
# skip non-rotational disks (indicators: rotation rate or acoustic management)
spin_rate=`udevadm info --query=all --name=$dev | grep 'ID_ATA_ROTATION_RATE_RPM=' | cut -d= -f2`
test -z $spin_rate && spin_rate=0
aam=`udevadm info --query=all --name=$dev | grep 'ID_ATA_FEATURE_SET_AAM=' | cut -d= -f2`
test "$spin_rate" == "0" -a "x$aam" != "x1" && continue
logger -t diskspindown "Setting spindown time to 60min for $dev ($model, $size)"
# set APM to allow spin down (ignore failures - drive might not support it)
hdparm -B127 $dev >/dev/null 2>&1
# set timeout to 60min
hdparm -S242 $dev >/dev/null
done |
|
This is something that would make me buy a 5 year subscription instantly 👍 |
|
@maxhq Thanks for all this excellent info, I particularly like the per pool power down idea. Please update the following forum thread with development on this issue: http://forum.rockstor.com/t/smart-status-and-disk-spin-down/793/7 |
|
Taking a quick look at this again now. |
Currently a static placeholder. Improve comments on columns.
Mention the (currently in development) task time window limiter as a way to increase disk idle periods.
Also updated a few older comments to help avoid further confusion with device names.
We are simply setting the idle spin down so don't need terminal feedback.
Improve comments on hdparm details.
Thank's @suman for pointers on this.
|
Disk Power Status is on the way: |
Also disable but don't hide the 'Enable' tickbox for these settings to maintain affordance for these settings existence for future visits. If we can't read them we should make no attempt to adjust them.
If we look at the AAM current value rather than just: ID_ATA_FEATURE_SET_AAM=1 we get a more reliable indication of rotational nature. Based on an msata device TS32GMSA370 which reports having AAM (Automatic Acoustic Management) which was previously assumed to be an indicator of a rotational device. Real rotational devices appear to have a non zero: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE via udevadm.
Also add safeguard to ensure no apm setting is applied when enable_apm is unticked. The apm 0 level is used as a flag to our existing sub system to set this up.
|
Linking to recently closed pr for collaboration purposes (closed due to deleting and recreating the github branch): |
|
remaining issues:-
|
With this option we send a flag value of -1 (normally 1-255) for the spindown time to indicate we want a current setting (if any) removed rather than updated or added (if non exists). On receiving this value we don't test the now nonsense hdparm command, as it would make no sense, and go ahead and use the existing mechanism to update our systemd file but this time by removing an existing entry.
Currently buggy but commiting as save point. Intended to disable and remove the systemd file when no remaining ExecStart lines remain.
Additional clauses to deal with removing non existing config and improve file management a tad by not copying our edited file if we are then to remove it directly afterwards. Also don't accidentally start a service file with no entries, could happen when creating a new but empty config via the remove function when no config existed.
This is important as the file is auto edited / maintained and so is expected to be of a certain format. The comments indicate this.
When we try and update the slider from a non numeric value from our apm_value text entry the slider and text box can end up dispalying NaN. Avoid by trapping isNaN and not passing to slider as then our in place form validation can deal with it in a more friendly fashion.
Brings in line with newer format. Changing only in hdparm and apm columns as already removed in other columns up stream.
To aid with upstream changes where refactoring has split the helper we use currently into many smaller ones like this.
|
Currently doing final testing prior to submitting pull request for review. |
Thanks to @maxhq on GitHub for their review which lead to this commit. Minor comment improvements also added.
As our edits rely on this template we should recognize it's non existence and log accordingly.
Minor surface reformatting of recently changed code.
|
The power down feature works great but I get the following warning from systemd when the service unit is updated: |
|
@maxhq Thanks for the report and I'm chuffed it's working for you. We have a few similar systemd file rights warning on some other services as well. Doesn't look like it's a problem but yes this is definitely something that needs to be sorted at some point. Started happening a few releases ago and I suspect it's down to some upstream policy changes on such things. Would you mind stating what drive models you have had success with and if they needed any non default apm settings; especially useful if the drives are a popular model. Though this discussion may well be better located on the forum in a thread of it's own, but anywhere is good really. Thanks again for you input. |
|
@phillxnet Sorry: bad news. Powering down only seems to work for my Seagate Barracuda ST1000DM003-1ER162 disks. I set APM to 127 (default: 128). |
|
@maxhq Well I'd rather see this as good news actually, at least it works on some drives.:) . There may also be some upper limits imposed by as yet undetermined factors ie a couple of (Leaving a browser open on some pages of Rockstor's WebUI can inhibit spin down, this has been noticed most on the disks page so far) Given that this issue is now closed we are likely to get more eyes on this if we continue in the forum thread that is now open to work out what might be done to improve things. As you indicate we are not likely to safely achieve a 100% success on this but there is definitely room for improvement, especially given the length of time it's been available / in development. Also the big hw players in this field also struggle with this one. Seems many drives just don't always behave as expected. Thanks @maxhq I think with a little more forum chat we can get more success on this one going forward and work out what needs to be issued on GitHub in manageable chunks. Please do open a forum post with specific finding on particular models as this is bound to help. I am definitely interested in refining this a little more at least, in fact that referenced thread may have already brought up an easy improvement that may be worth testing. Cheers. |
Currently it seems the only way to set / enable drive powerdown is via cli hdparm commands.
Now that Rockstor has hdparm by default we can add a facility to set this figure on each device.
Issues:-
Drive names change but that is dealt with at some level elsewhere I am just not sure how we translate that to the device parameter that hdparm takes, presumably via the same function that shows the drive name in Disks table.
Reasons:-
Power / noise save.
Avoid users having to enter eg /sbin/hdparm -S120 /dev/sdb above initrock -x entries in /etc/rc.local to enable 10 min power down. (a value of 239 sets a 20 mins power down)
Obvious place to add this interface might be an additional column or icon in Disks. This might then also equate to the current power state. I believe smart can relay the drives current power state so we could poll from that database but I think it better to have a dedicated entry / mechanism for power setting / state read as then lighter and can be polled without drawing in all of the smart data.
Options in this drive setting - set how long before drive enters sleep (no disk motor activity) state and an instant sleep mode option on each / all drives.
The text was updated successfully, but these errors were encountered: