testdasi

Use 4.2. 4.1 is buggy.

Are you getting that error from Windows (cuz I'm pretty sure that's a Windows error)? Try deleting the file from the console.

Unraid and lower power can go together fine. Gaming + low power is like trying to do an F1 race with a Fiat 500.

A docker or plugin creates those since I don't think they are native to Unraid. For example, my Calibre docker creates a Trash folder (but never uses it as far as I can tell).

You may need to balance your btrfs pool. Read the FAQ which johnnie mentioned how to do it. That's one cause of spurious out of space error. Another possibility is that a RAID 10 with 4x1TB and 2x4TB to give 6TB available space is just not a viable option. Doing RAID with uneven drive sizes is generally not a good idea. Traditional RAID doesn't let you do that. I think your pursue of max speed with (presumably SATA SSD) is heavily misguided. What "high demand function" are you doing? A game drive does not at all offer any perceivable improvement going from SATA to NVMe (or as I have tested, even SATA to Optane 905p!)

I can see the mergerfs docker under Advanced View of the Docker tab on the GUI. It's greyed out like orphan but it isn't deleted by the orphan deletion script so I manually deleted it using the GUI.

I would +1 on this too.

How would rclone union treat RO+RW mix? In other words, will there be CoW? 🐮

They don't exist.

You probably want to attach diagnostics (Tools -> Diagnostics -> attach zip file) Also, up top you said you are passing through the 970 Pro but below that you said passthrough 970 Evo Plus. Which one is passed through? What method did you use (ata-id? scsi bus? PCIe device?) 2 things you might want to try: Start a new config, pass through just storage + GPU and nothing else (i.e. no USB device / controller). I have had experience with strange delays on the Tianocore stage due to USB devices not doing handshakes properly. Go to you BIOS and look for any kind of power saving settings and turn them off / to max performance. I haven't had X99 for a long time so things are a little vague now but I remember there was a power-saving related thing in the BIOS that caused me quite a bit of troubles with Unraid VM.

The "moving to the cloud" is done through the upload script so if you don't run the upload script then your local will remain local forever.

...but if you write to a file that exists on one of the RO locations, it will refuse to write. Radarr/Sonarr requires full write capability to ALL content of the folder. Enabling full write on a mix of RO and RW content requires CoW which is not supported by mergerfs.

You can't mix RO and RW like that with mergerfs. It will not let you write to any file that is on the RO source since it doesn't support CoW (copy-on-write). To use a mix of RO and RW, you need to use unionfs (which was in the older versions of the script) and of course not have the mergerfs benefits. I guess the important point is why you would need the rclone mount to be RO.

You probably misunderstood the Service Accounts section. SA's can allow you to bypass limits, including API limit, (just switch to a remote using a different SA) but that isn't how the SA's are used in the script. SA's are basically the same as having additional client ID + secrets. (so the answer is yes on your 2nd question). Generally though, you shouldn't be maxing out API requests. The API limits are very generous so you need to resolve the root cause first i.e. whatever app / docker that is crushing it. The first hunch is subtitle-related apps. They have been known to cause problems with API limits.

Probably not. Why do you need so many tabs? Must you use Chrome? Also 15 tabs at 99% CPU load is a bit much. You must be doing something quite intense with those tabs.

It's an rclone option e.g. --log-file=/mnt/cache/mount_rclone/rclone/logs/upload_sa_06.log

@jonp: How much RAM would you need to start seeing benefits of huge pages? Is it only applicable to people running a lot of VM? What happens if my hugepage total doesn't match my VM RAM allocation?

Really like the new upload script - enough to completely switch to using Service Accounts now. Very easy to customize as well e.g. have dedicated log files for each of my 11 team drives + sharing 100 SA's among them so now my big backup job can complete overnight. Also found an unexpected extra use for mergerfs - to pool multiple external USB SSD's to make up a single pool for my offline backup. The "least used space" policy is serviceable with mixed-size pool to distribute data as evenly as possible (I prefer most free percentage but I don't think that's an option).

No, not those settings. Power & Sleep -> Additional power settings -> Choose what the power buttons do

My Win10 VM's + Ubuntu VM's would, without fail, shutdown if I stop it from the GUI. If it doesn't do it for yours, you might want to check your Power Options for Power and sleep button settings as the first suspect. Btw, if your VM freezes then only a Force Stop will work.

I had a close look at the new scripts (mainly for the --drive-stop-on-upload-limit option) on Github and I have to say it makes the old ones look like Neanderthal stone tools. 😅 Am I right to say these are the new features compared to the old scripts? CreateBindMount - so the rclone download / upload goes through a different IP address from the server IP? mergerfs instead of unionfs - for hardlinks + no COW Service Accounts - automatic switching of upload accounts Backup / Upload switch - rclone sync vs rclone move Variable-ize various things instead of hard-coding BW Limit by time - looks like it's a rclone functionality and there's no logic in the script, unlike (1) -> (4)? Just want to double check before I selectively adapt some to my current (old) scripts. A small proposal: why don't you also variable-ize the script location (/mnt/user/appdata/other/rclone/remotes)? Seems a bit out of place for all the other paths to be variables and this one is hard-coded.

rclone creates the log with weird permission so you have to use the console (either ssh in or through the CLI) to change permission and owners.

That bug is academic because you should not be using 9p (which is required to mount the "share" inside the VM template) due to the terrible performance.

That is very much misguided. I thought these "use ram for pagefile" kinda myths should all have been debunked by now. Just assign more RAM to your Windows VM or use baloon functionality if you want flexible RAM assignment.