Guzzi

Members
 View Profile  See their activity

  • Posts

    219

  • Joined

  • Last visited

 Content Type 

Everything posted by Guzzi

  1. Guzzi
    @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. Guzzi
    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. Guzzi
    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. Guzzi
    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. Guzzi
    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. Guzzi
    I have the same issue, running on a Pentium G4600 - also waiting for a solution...
  7. Guzzi
    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. Guzzi
    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. Guzzi
    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. Guzzi
    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. Guzzi
    Nice one - would drastically reduce the time data on cache drive is unprotected (if cache is not mirrored) :-)
  12. Guzzi
    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. Guzzi
    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. Guzzi
    ... 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. Guzzi
    ... 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
  16. Guzzi
    AFAIK it's not possible at the moment, I would also like to request this, as anytime I do longer writes to my cache SSD it goes 50C+ making all fans speed up unnecessarily. +1 from my side - same situation: using a SSD as cache drive which usually operates with higher temps than the HDs, thus when things are using the cache drive, fans are spinning up to full speed, which is not necessary. Simplest solution for this would be to add a setting, that allows to exclude certain drives from the calculation of the max drive temp. The script already excludes the flash drive: # 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` # 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) So might not be too hard to add a setting for exclusion for other drives too!?
  17. Guzzi
    +1
  18. Guzzi
    This is not possible yet! I have made a change though, which allows to set the temperature threshold values for each individual disk, and overrule the global settings. Hi bonienl, I'd very much appreciate, if the fancontrol plugin could also have either individual settings or the possibility to ignore the cache disk - same reason as above: the cache disk is a SSD and quickly reports high temperature, resulting in the fans going to full speed, though the hard disks are still in the low temp region. THanks for all your work!
  19. Guzzi
    Thanks for the hint - indeed, that is a cheap and obviously better solution than the sil3132 based cards.
  20. Guzzi
    Thanks Johnnie, that explains my pcheck limitation on my boxes - as I have 2xLSI2008, 6 onboard plus this PCIe card. It seems, there is no better alternative for PCIex1/2-port available, right? (Don't have a 3rd slot for 3rd LSI card available either...)
  21. Guzzi
    What I noticed and posted already some time ago is, that the read counts in UnRaid GUI are not counting up the same on parity checks. With V5.x, the counts ("Reads" in GUI) had been very close to be the same for all disks, which seems "logical" (assuming, nothing else accesse the disks except the parity check). With V6 they have big differences. Didn't get an answer from Tom yet, how and where those counts are taken in the software - maybe that could give a hint why and where the speed degradation is caused.
  22. Guzzi
    Yeah, I was worried about that. The removal of the "if" condition suggested by Guzzi has the side effect of the script taking too long to run. I'll have to think about how to fix it. That's probably caused by harddisks, that do not support reading temps when spun down !? Maybe have a look at how it is solved in myMain - there I do get temps even when HDs are spun down, but seems, that those scripts do handle also other brands of disks that do not support temps when spun down ...
  23. Guzzi
    Under workgroup settings, it shows a win10 laptop as elected master. While this machine has the "highet" win version, the eletion is incorrect, as there is a domain controller on the net, that should be elected as master browser !??
  24. Guzzi
    What I see there is what I noticed myself: The read counts are a lot different - e.g. 75k vs. 103k. I knwo they are not always "exactly" the same, but with my build on unraid 5 they were usually very close (unless there was any trouble with a respective disk). @Tom: from were does unraid get those counts? Does it make sense to activate debug logging of the sas2lp driver to see, if there is something strange happening causing re-reads - which could of course slow down performance and reduce overall throughput? Obviously, we do NOT end in read errors - as noone so far reported that reads really do fail ...
  25. Guzzi
    This symptom is very similar to one I was having earlier, by any chance do you have any Samsung disks model HD203WI or HD153WI? If so see here: http://lime-technology.com/forum/index.php?topic=42384.0 No, no Samsung disks, they're all WD (of different sizes) - and I had hight parity check speeds under unraid 5 with the same disks.