PSteward

Hello! I've been trying to find a solution to the issue of linux and reading/controlling fans, I stumbled upon liquidctl and the existing docker got me on the path to build something myself that reads hard drive temps, averages them and sets fan speed based on that. I am using the NZXT RGB & Fan Controller - AC-CRFR0-B1-6 and focusing only on controlling the fan speed (fan1, fan2, fan3). Here is a docker: pstewardyul/liquidtemp:latest Variables needed to set are: THRESHOLDS_ENV - Set the temperature thresholds that will change the fan speeds - DEFAULT "20,25,30,35,40,45" FAN_SPEEDS_ENV - Set the speeds that will change with the threshold temperatures - DEFAULT "20,30,40,50,60,100" EXCLUDED_DRIVES_ENV - If you need to exclude drives from the average calculation - NO DEFAULT - EXAMPLE "/dev/sda,/dev/sdb" FAN_QUANTITY_ENV - Set to 1, 2, 3 (how many you are connecting to your controller) - DEFAULT "3" The container requires "privileged" to read/control related hardware. Also recommend to set "--log-opt max-size=50m" in extra parameters to limit the log size as every minute the script will run to check/update fan speed, these changes are viewable in the log. If you don't set any variables - no worries - it will load defaults (except the log limit). This an AMD64 docker image, not sure how to work with the other platforms, and just started with making scripts and building docker this afternoon so even though it works on my system, not sure of others! FYI - The script just works with /dev/sdX not NVME, also some /dev/sdX don't produce the smart output compatible (like my kingston MSATA). The script can be found at "/usr/local/bin/fan_control.sh". EDIT: Changed from hddtemp (causing issues with spun down drives) to smartctl and added more error checking. --Phil

So to conclude to this, I haven't had any more read errors. I upgraded my power supply and assume all previous READ errors were related to running all drives at once since all other times everything worked fine but obviously didn't pull that amount of wattage.

I stopped what I was doing and did new config and then selected the option to re-use the existing parity before starting the array. Now I am running the parity check again (error correcting) and here I am: Total size:16 TB Elapsed time:3 hours, 32 minutes Current position:2.41 TB (15.1 %) Estimated speed:179.5 MB/sec Estimated finish:21 hours, 2 minutes Sync errors corrected:3 As a note, I haven't physically changed anything (not in the same city as my server anyways!), BUT I did spin down ALL off my un-assigned drives. So I am leaning towards not getting enough power and already ordered a 1200w power supply for absolute overkill just in case.

Thanks for the response. I will investigate power issues, but to be clear there is more usage during a parity check/rebuild than during a parity build? My parity build had all drives running full for 1.5 days without issue.

Ok, more info. During the rebuild it gave me read errors on disk1 (one of tons): May 12 19:16:53 HOMESERVER kernel: md: disk1 read error, sector=221271952 SO I plugged this into badblocks (badblocks -v /dev/md1/ RANGE OF SECTORS) AND there are zero 0 bad blocks found and no read errors. Data is good, Smart test is good, drive is good, badblock read is good only conclusion I have is that is a system bug with Unraid parity?

Ok I don't know what the hell is going on, now my disk 1 is getting read errors during this rebuild....what is happening?? First disk 2 now disk 1 (both 16tb Seagate). I removed disk 2 again and am copying all data off, and I am copying disk 1 off to another drive too temporarily. This is nuts all this time and copying and copying, why if I never had issues with these drives EVER does this OS have issues? I am copying ALL data from both these drives with ZERO errors but the moment parity check or build is involved they have read/write errors. homeserver-diagnostics-20230512-1920.zip

Hello! I finally completed the parity drive addition and everything was a success. I was curious what happens when I pressed the check parity button after this completion (to see how long it would take) and suddenly a drive got an x and started having errors (newer never had issues before). I don't want to lose any data and am not sure how to proceed from here to get it back into the array (without out an X). Edit: I read a ton and removed/re-added and now it's rebuilding but I don't understand what happened as the drive was fine up until I clicked on parity check (I saw write errors after it was disabled, unfortunately didn't save log before rebooting). There were no physical changes, the drive has been fine for it's 1.5 years of existence, and it was perfect when added to the array, data moved to it, during parity creation. What could cause this by clicking "parity check"?? Please let me know! Thanks, --Phil homeserver-diagnostics-20230512-1832.zip

@Manuel-DG Switch to disk shares, after doing that all my SMB issues were solved (so far). User shares SMB can move individual files but expect constant freezing in Windows explorer when just trying to view folder contents. There is a thread on speeding up things and one the first items it to stop using user shares. Thanks, --Phil

Hello! Is there a way to change the port from 9993 to 9994 (and unbind from 9993)? I tried with a local.conf file inside the container but it didn't work. Thanks! --Phil

Hey Itimpi, Hmmm....that is true (125 MB/s). Not sure why Windows transfer speeds (Teracopy) would have reflected differently, but also on the transfer side internally. Any thoughts for that? Thanks, --Phil

Hello! I just made the leap into Unraid from Windows and am mostly setup (no parity drive just yet as I still have some copying between unassigned and pool drives). I am having some issues that I would like to resolve: 1. I setup an SMB share and when I am connected to the share in Windows (10 PRO) my mouse is constantly alternating between a normal cursor and loading cursor. Never seen this behavior, what would cause it? Connection doesn't seem stable. 2. Drive to drive seems slower, when I was backing up my main drives to other drives to empty them (In Windows) to get them into the pool they would copy 170-200 MB/s internally, and now using MC (in Unraid) moving the data back (No Parity drive yet) after pooling they are around 120-150 MB/s (NTFS to XFS). Notes: I setup link aggregation and this did not improve my copying (shouldn't have as before I just used 1G ethernet in Windows and it was faster but thought I would try.) I am linked at 1G on both ethernet ports (as per Unraid). I am not copying from a drive that is in use. I am not using Parity just yet, again I am copying FROM the server so shouldn't make a difference. Copy TO the server, the same speed (105 MB/s) persists. Any assistance would be appreciated! Thanks, --Phil