Open rct opened 2 months ago
I was in need of something exactly like this, and found this issue.
Is there any plan of adding something like this @adelolmo ? It would probably be even better to add it to the executable itself, hd-idle --state sda
to get the state.
To be honest, I've been very reluctant to add any functionality that deviates from the original intention: put disks on standby. Maintaining this piece of code has a very low priority for me and I don't see that improving in the future. That said, getting the state of a disk shouldn't be a big task to implement. @firasdib How do you imaging it working? Should it also return the state from all disks if no extra argument is given? Should it return plain text/json/yaml?
@rct Out of curiosity, what would be your usecase? I'm trying to understand how this change would be used.
@adelolmo That makes perfect sense, it's a simple utility, but I believe this change remains true to the core purpose of the software. I primarily envision this being used for machine parsing, so any predefined parseable format is fine, for example JSON.
How it should work would depend on how expensive this operation is. If it's a cheap operation, then it would probably make sense to have the executable simply dump the data to stdout, and then the user can do what they want with it (write to disk, read as is, etc). If it's expensive, then having it write periodically to disk would probably be a better idea, and then consumers can read that file as they see fit.
Obviously this assumes the user has not configured the state file to be written to a disk hd-idle is supposed to put to standby.
For me, I want to continuously query the SMART data of my drives, without disturbing standby or deep EPC states. This utility already knows when drives are idle, and I can use that "for free".
I took the liberty of simply adding a statefile, using the debug output format, see fork: https://github.com/adelolmo/hd-idle/compare/master...firasdib:hd-idle:master
No clue if this is the best way to do it, but I'm not a wiz with Go, but I gave it a shot.
[This is really meant to be a discussion but that's not enabled on this repo.]
In thinking about what hd-idle currently does by processing
/proc/diskstats
and the limitation that it might not be able to detect disks that get spun up but don't actually do any reads or writes, I'm wondering about the possibilities of extending hd-idle:A separate script could periodically check the state of a drive
smarctl -n standby
or other appropriate command, but it would need to know if a drive is supposed to be idle.Instead of re-implementing the logic of hd-idle, it would be useful if it could get that state from hd-idle. The current logfile doesn't have enough info to be useful in this regard:
However, hd-idle provides the state information when in debug mode:
So my current thought is adding a state file option to hd-idle, where the above data could be periodically written for use by other scripts and utilities. Just like logging, the user would have to take care not to spin up a disk every time the state file gets written.
I think this might be more general then other options like adding additional timers/command options to hd-idle to run a script to verify if drives are spun down