Phoenix Down

It just started working by itself recently. No changes on my part.

Nope. Had to stick with Yahoo Mail for this.

If we move to using the plug-in, we should remove any existing RAM-disk code from "/boot/config/go", right?

I just checked, and I misspoke. It has been so long that I forgot what I did. I actually have it set up as bash script that is executed daily via User Script. I seem to recall my modifications kept getting wiped out. Probably from every time Autofan updates. It's possibly less of an issue now, since the last Autofan update was in February 2023. Here is the script. You will need to substitute the path to your own modified autofan script. Once the modified script is copied over, you need to kill then restart autofan for each of your fans, so the updated version can take effect. You can find the exact commands in the system log when Autofan starts. Don't just copy mine, since the argument values are specific to your system. #!/bin/bash echo Copying modified script from '/mnt/user/Data/Scripts/autofan' to '/usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan' cp /mnt/user/Data/Scripts/autofan /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan echo Done. echo echo Starting Autofan... echo /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm3 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan3_input -q echo echo Waiting 5 seconds before restarting... sleep 5 echo /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm3 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan3_input -l 25 -t 35 -T 55 -m 5 /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm4 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan4_input -q echo echo Waiting 5 seconds before restarting... sleep 5 echo /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm4 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan4_input -l 25 -t 35 -T 55 -m 5

I know it's super late, but I just saw this. Not sure how I missed it the first time. Hopefully my fix worked for you.

I reported this issue 2 years ago, along with the fix. Sad to see it's still an issue. But I understand that developers are volunteering their own time, and they have their own lives, which should always takes priority. In any case, take a look at my post and the associated fix. I have a local fix in place, and set it up so the local fix is applied at Unraid startup (place in the go file):

Running into the same issue with Proton Mail. Anyone with any resolution?

Not sure; I did not run into this issues for any of my 8 disks. Maybe there's a hint in this thread:

Just trying to eliminate variables, see if it’s an issue with your large disk or something else.

What happens if you tried a different disk first?

Have you encrypted any other disks in your system? Were they successful?

Check the system logs (top right, left of the solid circle with a question mark). That sounds like the format was unsuccessful for some reason.

See my reply above: Did you start the array back up after you changed the disk type to "XFS Encrypted"?

Check to make sure you copy and pasted the correct checksums into the RAM disk script. Maybe you missed a digit at the end.

If your Unraid version is different than @Mainfrezzer's code example, then it's possible those files are also different. So yes, you should update the RAM DIsk code with your own checksums. Note that doing this doesn't mean the RAM Disk code won't have any issues, just that the code won't abort itself. It might or might not have any issues, but we don't know until someone tries it out whenever a few version of Unraid comes out.

If you look at this line: echo -e "45361157ef841f9a32a984b056da0564 /etc/rc.d/rc.docker\n9f0269a6ca4cf551ef7125b85d7fd4e0 /usr/local/emhttp/plugins/dynamix/scripts/monitor" | md5sum --check --status && compatible=1 There are two files in the format of "md5_checksum path_to_file": 45361157ef841f9a32a984b056da0564 /etc/rc.d/rc.docker 9f0269a6ca4cf551ef7125b85d7fd4e0 /usr/local/emhttp/plugins/dynamix/scripts/monitor You can use md5sum to generate new checksums on those two files, like: md5sum /etc/rc.d/rc.docker Sounds like @Mainfrezzer's code already includes the new checksums for 6.12.4. But you can double check yourself if you want.

I'm holding out for RAM Disk compatibility before upgrading to 6.12.

Just wanted to say thank you @mgutt! I had an earlier version of your RAM Disk installed. Wasn't even sure of the version, as it didn't have the version number in the comments. Must have been from a couple of years ago. In any case, after upgrading to 6.11 recently, I noticed that my Disk 1 would have writes to it frequently, which wakes it up along with my two parity disks. This is despite me emptying all contents from Disk 1, and all of my Dockers running from the SSD cache pool. Also, new writes should have gone to the cache pool and not the array. I spent hours watching iotop and dstat, and I was about to pull my hair out when I noticed that Disk 1 would only wake up when certain Docker container is running (specifically DiskSpeed and HomeAssistant). On a whim, I looked to see if there is a newer version of the RAM Disk available, and found this thread. I updated the RAM Disk code, and viola! No more disks waking up! Still not sure why certain Dockers are writing directly to the array or why it's always Disk 1, but I'm glad the new code fixed the issue

Awesome, thanks Jorge! Can I assume that this option is enabled by default? When did this option get enabled in Unraid? I found some posts as early as 2-3 years ago that still said TRIM is not supported on encrypted SSDs on Unraid.

Does anyone know what's the latest on this? In theory it is possible to enable TRIM on LUKS encrypted SSDs, but is it enabled on Unraid? https://www.guyrutenberg.com/2021/11/23/enable-trim-on-external-luks-encrypted-drive/

Understood, thanks for the reminder 🙂 Turns out it's a bit easier than the video. Once you've emptied a drive using Unbalance, you just have to stop the array, and then change the disk type of the disk you just emptied to "XFS Encrypted", then start the array back up. Lastly, format the disk and that disk is converted.

Is this 5 year old guide from SpaceInvader One still the best method to encrypt an existing array?

Is there anyone actively maintaining the Autofan plug-in? I've already presented the fix. Just need the maintainer to merge in the one-line code change.

Hi @bonienl, is this the right channel to report a bug? If not, please point me in the right direction I've been noticing an issue with Autofan in the last couple of months. It seems like whenever all of my HDDs are spun down and only my NVME cache drives are still active, Autofan gets confused and thinks there is no active drives, and shuts down all of my case fans. This causes my NVME drives to get pretty hot. After digging through the Autofan code, I discovered the issue in function_get_highest_hd_temp(): function_get_highest_hd_temp() { HIGHEST_TEMP=0 [[ $(version $version) -ge $(version "6.8.9") ]] && HDD=1 || HDD= for DISK in "${HD[@]}"; do # Get disk state using sdspin (new) or hdparm (legacy) ########## PROBLEM HERE ########## [[ -n $HDD ]] && SLEEPING=`sdspin ${DISK}; echo $?` || SLEEPING=`hdparm -C ${DISK}|grep -c standby` ########## Fix is below ########## [[ -n $HDD ]] && SLEEPING=`hdparm -C ${DISK} |& grep -c standby` ################################## echo Disk: $DISK - Sleep: $SLEEPING if [[ $SLEEPING -eq 0 ]]; then if [[ $DISK == /dev/nvme[0-9] ]]; then CURRENT_TEMP=$(smartctl -n standby -A $DISK | awk '$1=="Temperature:" {print $2;exit}') else CURRENT_TEMP=$(smartctl -n standby -A $DISK | awk '$1==190||$1==194 {print $10;exit} $1=="Current"&&$3=="Temperature:" {print $4;exit}') fi if [[ $HIGHEST_TEMP -le $CURRENT_TEMP ]]; then HIGHEST_TEMP=$CURRENT_TEMP fi fi done echo Highest Temp: $HIGHEST_TEMP } Check out the line I marked ########## PROBLEM HERE ##########. Specifically middle condition (sdspin). [[ -n $HDD ]] && SLEEPING=`sdspin ${DISK}; echo $?` || SLEEPING=`hdparm -C ${DISK}|grep -c standby` "sdspin" is a shell script that runs hdparm -C on the NVME device. Here's the contents of sdspin: # cat /usr/local/sbin/sdspin #!/bin/bash # spin device up or down or get spinning status # $1 device name # $2 up or down or status # ATA only # hattip to Community Dev @doron RDEVNAME=/dev/${1#'/dev/'} # So that we can be called with either "sdX" or "/dev/sdX" hdparm () { OUTPUT=$(/usr/sbin/hdparm $1 $RDEVNAME 2>&1) RET=$? [[ $RET == 0 && ${OUTPUT,,} =~ "bad/missing sense" ]] && RET=1 } if [[ "$2" == "up" ]]; then hdparm "-S0" elif [[ "$2" == "down" ]]; then hdparm "-y" else hdparm "-C" [[ $RET == 0 && ${OUTPUT,,} =~ "standby" ]] && RET=2 fi If I run the command directly: # hdparm -C /dev/nvme0 /dev/nvme0: drive state is: unknown # echo $? 25 This the same exit code that sdspin returns: # sdspin /dev/nvme0 # echo $? 25 My cache drives consists of 2x Silicon Power P34A80 1TB m.2 NVME drives. Apparently hdparm cannot get their power state, and because sdspin is looking for the word "standby", it never finds it. More importantly, the middle (sdspin) condition always sets $SLEEPING to sdspin's exit code, which is 25 in this case. And because 25 is not zero, this causes the script to think all disks are in standby mode (even though my NVME drives are still active), thus causing Autofan to shut off all case fans. My fix is simple: remove the middle condition: [[ -n $HDD ]] && SLEEPING=`hdparm -C ${DISK} |& grep -c standby` Because the last condition is looking specifically for the word "standby" and not just taking the exit code, it works. This is because hdparm says my NVME drive's state is in "unknown", which is not "standby". That means the script correctly considers the NVME drive as NOT in standby. I've locally modified the Autofan script and it's been running correctly for a few weeks. Unfortunately my local changes gets wiped out every time I reboot the server, so I'd appreciate it if you or the author can update the script to fix this bug. Thanks in advance!

You know, I haven't actually tried that. Let me try and let you know if it doesn't work. Thanks!