je82

think a simple google search answered my question:
ill be using the parity check tuning by @itimpi until i upgrade my unraid to a more modern version

You can find the digest used by running
Replace "lscr.io/linuxserver/mariadb:latest" with whatever the id of the container you want to extract the digest from
 
But i could not find the exact digest among the tags so i had to query database by running SELECT @@version; which gave me the version and solved the issue.

Think i found the problem, it will take some time to test
 
I had defaults
vm.dirty_background_ratio 10%
vm.dirty_ratio 20%
with 128gb ram
 
looks like a bad thing to do, i hope this will resolve the oom-killer issue, time will tell. If you have other ideas, i'd love to hear them.
 

Think i answered my own question, i just expected it to be faster, my cpu literally sleeps while writing at 110mb/s to the xfs encrypted cache volume so to me it seems like there is a hardcoded limitation either inside the xfs encrypted protocol or inside unraid for whatever reason.

nevermind i see now that i somehow glossed over this, it was mentioned in there, all is good.
 
edit: a good thing to add for future unraid releases is the notice that you have to enable this option "Host access to custom networks: Enabled" under the advance docker setting in order for it to work, right now it only says you have to make a static route in your router and nothing more. otherwise big props to the developers, wireguard was very simple to setup and works liek a breeze!

had to "umount -l /dev/loop2" to get the array shut down...
 
not sure what happened here, maybe it has nothing to do with the Appdata cache name and maybe more to do with me having some dockers on auto run and shutting down the array before all the autoruns have been processed making the docker process lock up?

Found the issue, a sync script was setting "+" on the backup share, causing issues with new folder permissions. Solved.
 
root@NAS:/mnt/disk4# getfacl Backup/
# file: Backup/
# owner: nobody
# group: users
user::rwx
user:nobody:rwx
group::rwx
group:users:rwx
group:3006:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:nobody:rwx
default:group::---
default:group:users:---
default:group:3006:rwx
default:mask::rwx
default:other::---
 

Welp great, time to migrate away from google, i should have done it a long time ago
 
 
More secure yeah... so secure i cannot even access it anymore using my own credentials which are far beyond anything you can bruteforce, thanks google
 
More of you will probably see this soon.