Michael_P

You shouldn't need a swap file, you have plenty of RAM for what you're doing - you just have to make sure your container's folders are correctly mapped to disk, and they are limited to whatever arbitrary amount you want to set. jellyfin and immich are pretty big hogs if not configured correctly (watch a couple movies at the same time and bang, OOM) - HA can get wonky too, but I don't use it so I can't help you there. From the log in your OP, on the 13th and 18th the host ran OOM at about the same time - 0337 and 0343 respectively - so you can also see if there's a scheduled process in any of your containers kicking off around that time (maybe every 5 days, too?)

Looks like a case of just too much going on at once and the reaper just pulled Docker from the top of the list - if it happens again, you can limit the RAM available to the containers or change their config so any file storage is on disk instead of RAM (especially jellyfin). Reboot if you haven't already to clear the log

What I mean is I wouldn't trust it with any irreplaceable data, anyway. Might get some more mileage out of it for storing backups and such

errors were all in a row, but i'd still relegate it to backup duty Pending Defects log (GP Log 0x0c) Index LBA Hours 0 8592654424 54379 1 8592654425 54379 2 8592654426 54379 3 8592654427 54379 4 8592654428 54379 5 8592654429 54379 6 8592654430 54379 7 8592654431 54379 8 8592654440 54399 9 8592654441 54399 10 8592654442 54399 11 8592654443 54399 12 8592654444 54399 13 8592654445 54399 14 8592654446 54399 15 8592654447 54399

Looks like Jellyfin tipped the scale a little too deep and ran the host OOM on the 27th and 28th, if it happens again you can change the config so it's not using RAM as cache. Reboot to clear the log so FCP stops warning you. Also, autofan is spamming your log, you ought to change the logging level to clean it up a bit.

Reliable and smooth at doing what? They're different operating systems that serve different purposes. I'm not even sure what you mean with windows screwing up Unraid - Unraid can host a Windows VM, but an update to Windows can't screw with the host. And you don't "plug an unraid USB into a Windows machine", it's either an Unraid Machine or a Windows Machine - it's not both at the same time

Whatever it's trying to do in RAM, maybe can be done to disk

That's what's being reported - the reaper is killing it when it exceeds the limit. Increase the RAM available to the container or put it on a diet. Make sure you reboot to clear the log so FCP won't trigger on it again

Do you have a memory limit set for your Radarr container?

Did a prankster hide one of those beepers in or near it

post the output of ps -auxf taking care to remove any passwords if you have VPN containers and the like

ps -auxf will tell you what's spawning what and the resources it's using, can be helpful tracking down repeat offenders.

It might actually just be docker killing it (doing it right for once), hasn't happened in a couple days so I wouldn't worry about it too much - if you have free RAM to play with, allocate a bit more to it or put qbittorrent on a diet so it's not using as much.

No, your host is running out of memory and killing what it thinks is using the most memory - and that it's continuously killing qbittorrent, that would be the likely suspect. Doesn't look like it from the logs but are you running any other containers?

May 14 04:48:11 Astaroth kernel: Memory cgroup out of memory: Killed process 3887080 (qbittorrent-nox) total-vm:2118364kB, anon-rss:2074044kB, file-rss:88kB, shmem-rss:0kB, UID:99 pgtables:4180kB oom_score_adj:0 it was repeatedly running OOM and killing qbittorent from when your logs started on May 11th until May 14th

Looks like qbittorrent was running the host OOM for a few days ending on the 14th, if you've since corrected whatever it was doing (probably folder mapped to RAM instead of disk), you can reboot to clear the log so FCP stops warning you. If it happens again, verify your folders are mapped correctly

I had an A770 for a couple years, sold it on ebay for what I paid for it and bought a 4070 super a few months ago before the prices went nuts again. The A770 was an absolute unit for transcoding and power efficiency, but it was a one trick pony in that regard.

When can we expect a stable version lol

Looks like Tdarr ran the host OOM back on May 6th. Reboot to clear the log so FCP stops warning you about it, and if it happens again change the config so tdarr is not caching transcodes to RAM

If you have 2 parity drives, you can replace two data drives. I'd do it in maintenance mode in case it goes south, so you can recover if another happens to fail during the re-build.

1 and 2 are a yes, but it would be a lot more efficient (power especially) to upgrade the CPU and mobo. Quicksync on the gen 8 and up Intel CPUs is really hard to beat. I have an i7-8700 in mine and never even notice when any of my family are watching movies

You'll find plenty of complaints from one camp over another camp, so it's not a black and white 'buy this and you'll be fine' kind of deal. My two cents is every WD drive that's failed for me has let me know way in advance (knock on wood) and let me get the data off of it, whereas Toshibas have just flat out quit, and Seagate drives will let you know they're going to fail right about the same time as they die and I have never been able to get data off beforehand. The biggest takeaway, back up your important data so a failure isn't catastrophic, because what's been good for me may not be so for you

This would be my vote

FWIW I avoid Toshiba drives like the plague - they just seem to up and die on me without warning

You shouldn't expose unraid directly to the internet, you should connect to it via the VPN.