Jump to content

Guzzi

Members
  • Content Count

    219
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Guzzi

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @limetech: Is it possible to add some verification within unraid that it gets the "real" status of the discs? Obviously, unraid thinks the disks are spun down, when they are not and thus doesn't try to spin them down automatically anymore - could we as a workaround at least have some e.g. hdparm-checks to get unraid internal state in sync with real state? hdparm always reports me the currect state on my tests. Currently, I have to do manual spinup or spin down to get to this ?
  2. I have the issue, that the GUI display and disks.ini file seem to not be in sync with the information about the spinning state of some hard drives. In the GUI, Dashboard and Main view show different states (for the disks affected): - Dashboard shows disk spun down (grey) and no tempareature - Main view shows disk spun down (grey), but shows temperature Current example is disk18 - looking into the browser debugger, the request http://192.168.0.21/webGui/include/DeviceList.php? path=Main&device=array&csrf_token=xxxxxx returns the info: .... <span>Device is in standby mode (spun-down)</span> .... Content of disks.ini for disk18 at the same time is: ["disk18"] idx="18" name="disk18" device="sdt" id="WDC_WD100EFAX-XXXXXXXX" size="9766436812" status="DISK_OK" rotational="1" format="GPT: 4K-aligned" temp="34" numReads="0" numWrites="0" numErrors="0" type="Data" color="green-blink" fsStatus="Mounted" luksState="0" comment="" exportable="no" fsType="xfs" fsColor="green-on" fsSize="9765006020" fsFree="1263003968" spindownDelay="-1" spinupGroup="" deviceSb="md18" idSb="WDC_WD100EFAX-XXXXXXXXX" sizeSb="9766436812" hdparm -C tells, the drive is active/idle, I assume this must be the correct state. So the issue seems to be, that some part report the drive as spun down and thus no automatic spindown command happens anymore. As a consequence, temperature stays high and IPMI-plugin (which reads info from disks.ini) can't reduce fan speed (which is correct behaviour). If I do a manuel spin down (or spin up) on "Array Operations" tab, it goes in sync again. I remember we had such behaviour some years ago, which was solved for a long time. ANybody else having the same issue and an idea how I could solve it? From where is the Devicelist.php call getting the information? Edit: This seems to happen especially with the WD-Red 10GB drives - smaller drives are not affected, as far as I can see. This explains, why it just started recently (when I added the 10TB drives to the array), but not before...
  3. And as mentioned by others - do never ever use bad drives - it is not worth the trouble you'll get - so if smart reports issues, you should really dispose those drives.
  4. If you really want to go with the old drives , I'd suggest you first test smart values for all drives, throw away the drives that fail or show many errors and then run preclear on the error free ones. Finally you should have a set of drives that should be good to go.
  5. I can confirm issues with sleep states of the drives. The states are even different between dashboard tab and main tab. Are they using different methods to get the drives state?
  6. I have the same issue, running on a Pentium G4600 - also waiting for a solution...
  7. Thanks for your explanations! So I'll have to live with the "N/A" temps obviously - and yes, I think it is not an issue in from operational view. I am really happy to be able to do that fancontrol, so again many thanks for your plugin!
  8. Ah, I remember, that in the past there was a discussion, that some drives DO spinup. I use WD drives since decades, so I never had that issue. So do I understand correct: 1.) display of the temperature can't be fixed anyway within the plugin, because it is using what unraid provides - only Tom could add an option to provide temp info for standby drives. I think I asked for this some time ago, so this probably won't happen any time soon. 2.) Fancontrol script ignores any device in standby - so what does it do, when ALL drives are down? Will it set the fans to minimum? Am I right, that this could lead to a too high temperature, e.g. when hdd fans are switched off due to the fact, that fancontrol script does not know about the hdd temperatures anymore? I think it is not a biggie, because making sure, that fans at least run at a minimum speed should be able to avoid that. Releated question: How tdo you get temperature from drives not in the array, e.h. an unassigned drive? Do you poll those separately? (Can't test myself right now, because I have only array drives currently)
  9. hi dmacias, first thanks a lot for this plugin, a real value add for those of us running x11 boards :-). I have one question: I use the fancontrol to control the fans for hdd cooling. Now, if all hdds are spun down, it shows temp "N/A". Is this intended? Or could we also show the temperature when the discs are down. I can get the temperature from all my disks when they're down on the command line: for i in $(ls /dev/sd[a-z] 2> /dev/null); do smartctl -a $i |grep Temp;done Would it make sense to use this at least as a fall back to determine the temps, when all are spun down? Thanks for all your work!
  10. Hi bonienl, seems the former attachment is gone during forum migration - still would like to ask you to add the exclusion of SSDs within the autofan script. The relevant change is here: # Obtain the ID of your flash drive (your flash drive is named "UnRaid" right?) flash=/dev/`ls -l /dev/disk/by-label| grep UNRAID | cut -d/ -f3 | cut -c 1-3` # Obtain the SSDs of your system ssds=/dev/`ls -l /dev/disk/by-id| grep SSD | grep -v part | cut -d/ -f3 | cut -c 1-3` # Count the number of drives in your array (ignoring the flash drive we identified) # NUM_OF_DRIVES=$(ls /dev/[hs]d? | grep -v "$flash" | wc -l) NUM_OF_DRIVES=$(ls /dev/[hs]d? | grep -v "$flash" | grep -v "$ssds" | wc -l) # Identify the drives in your array so we can test their temperature COUNT=1 # for d in $(ls /dev/[hs]d? | grep -v "$flash"); do for d in $(ls /dev/[hs]d? | grep -v "$flash" | grep -v "$ssds"); do HD[$COUNT]=$d #echo HDD=${HD[$COUNT]} # Uncomment for debugging COUNT=$[$COUNT+1] done function_get_highest_hd_temp() { [...] instead of hardcoded grep of 'SSD' this could also be replaced by a GUI editable search expression or regex...
  11. Nice one - would drastically reduce the time data on cache drive is unprotected (if cache is not mirrored) :-)
  12. I can confirm that I got S3 sleep working with both IBM 1015/1115 and SI3132 (that is with older AMD based motherboard). However, to my experience it is mostly depending on the motherboard and BIOS - I am also looking for a newer e.g. Skylake board that would still support proper S3 with unraid (and fancontrol!), but it seems, it is a try and error process... so if anybody has made positive or negative experiences it would be nice to read it here.
  13. I upgraded my board and unfortunately autofan doesn't work anymore, so can't test. ... is it the X11SSM-F that doesn't support autofan anymore? (Asking, because I thought about upgrading to that board too)
  14. ... I have had a look myself and did some tests, so I will post a modified autofan script. What it does is: - detecting the SSD drives in the system - exclude the SSD drives from the highest-temp-calculation You might want to add an on-off-switch to allow the user to enable/disable this part. Tested on my own system and it worked fine; however, I use 'SSD' to identify SSD-drives within the /dev/disk/by-id hive - and I am not sure, if this will work for all brands (works with sandisk SSD fine here). I also tested, that the script works, if there is multiple SSDs in the system - they would all get excluded (if they can be detected propertly). Note: If the detection is not reliable enough, an alternative implementation would be to set the $ssds variable manually in the config, letting the user select the devices to exclude. Hi bonienl, I know you're busy with latest GUI update implementation, just wanted to ask, if this could get either more testing or updated (maybe with an option) to the repo. Works fine for me, so I am personally fine with it, just have to overwrite it whenever I boot. @johnnie.black, as you were interested too, would you like to test it? Simply rename attached file of OP to autofan and copy it into /usr/local/emhttp/plugins/dynamix.system.autofan/scripts and restart the tool (e.g. update a setting in the GUI will restart it using the updated script).
  15. ... I have had a look myself and did some tests, so I will post a modified autofan script. What it does is: - detecting the SSD drives in the system - exclude the SSD drives from the highest-temp-calculation You might want to add an on-off-switch to allow the user to enable/disable this part. Tested on my own system and it worked fine; however, I use 'SSD' to identify SSD-drives within the /dev/disk/by-id hive - and I am not sure, if this will work for all brands (works with sandisk SSD fine here). I also tested, that the script works, if there is multiple SSDs in the system - they would all get excluded (if they can be detected propertly). Note: If the detection is not reliable enough, an alternative implementation would be to set the $ssds variable manually in the config, letting the user select the devices to exclude. autofan.txt