testdasi

@nuhll: Questions: Do you find a copy of a file in the "RW" location of your unionfs mount? (your unionfs should contain 1 RW + 1 RO - it's in the command). If yes to (1), have you tried to access the file in the RW location directly i.e. bypassing unionfs? If not, do a comparison of the file in the RW location vs the original in the cloud - something as simple as just try to play each copy of the file. I'm trying to eliminate the worst case scenario - that is you are having a cryptovirus trying to encrypt your data. If no to (1) then at least you know it's not something too serious. It's simply a matter of turning of things one at a time to see what is causing it.

I have run the scripts from SSH many times before and have never had any problem so I can tell you for a fact that if done correctly, it makes no difference between the CA Userscript vs SSH. The problem is "if done correctly" - too many variables as to what you did that may cause it to not work. Hence, run it in CA Userscript in background is the best solution.

But rsync on Unraid, which is Linux based, will do the same.

That's not duplicated file. Linux is a case-sensitive system, unlike Windows. So File1 and file1 are 2 different files.

Let me flip the question back: why do you need rsync? There are simpler apps out there to keep 2 folders in sync without needing endless loops (i.e. only run upon changes) e.g. Syncthing, Resilio Sync, etc. Sounds to me like you picked a tool beyond your skill level to solve a problem it may not be the the most suitable tool for.

It is. I have stopped using Crashplan and switches to using Google. The only caveat is there's a hard limit of 400k files per tdrive (soft limit of about 200k, beyond whiach performance is a biatch). If you think a portion of your backup can go above 100k then split it out to its own tdrive.

Can you do it with root user? 😱

Q35 machine. Do you have this section of code in the xml, before </domain>? If not, add it. Otherwise your GPU runs at PCIe x1. <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.speed=8'/> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.width=16'/> </qemu:commandline>

Hi Max. I suggest you post a request in the feature request forum. Not saying that LT will implement that but there's a better chance than posting in this old topic.

Simpler solution. Try updating right after a reboot?

It's a Linux kernel problem. People are already trying to help to find workarounds but if it's not fixed in the kernel, there is no guarantee whatsoever that these workarounds would work for everyone. Don't blame the tires when the engine breaks. You can't possibly expect everyone on the forum to drop everything to give you (free) bespoke advice on an on-demand basis. Such expectation is also not acceptable. Best course of action for you is to use the last Unraid version that works.

Everything hangs when a disk is spinning up - that's to be expected. A disk refusing to spin up doesn't sound like a UD problem. My HDD spins up fine when accessed.

Up from 6.7.1. No issue to report. Even my dual NIC doesn't have the same DNS problem.

When I was testing out various configs, I simply use User Scripts and do a simple cp to create a copy. I reckon someone more verse in shell script can sure create a folder based on time and cron it every hour or something.

Create a separate topic with a proper report of your problem and attach diagnostics. Posting a 3-line complaint on every release topic will not get you the necessary help.

So is it just newer kernel and restoring sqlite support?

What makes the plugin not easy?

Upgraded from 6.7.0. Forgot that I upgraded and tried to do it again.

Oops sorry I missed the "instant" keyword. It is not instant because Unraid will try to copy the file to the unionfs location and then delete the original. Unionfs isn't smart enough to realise the RW location is on the same media as your original.

What is your unionfs line in your mount script? That sounds like you set your mount_rclone as the RW location so when you copy file over, it tries to upload to gdrive live during the transfer. rclone_upload is instant because it's local until you run the upload script.

It sounds to me like you are trying to make Unraid into a FreeNAS clone, which it isn't. ZFS can be self-repairing because of its RAID design. Bringing the ZFS file system over to Unraid will not automatically make it self-repairing, because Unraid isn't RAID (i.e. what johnnie said a few posts back). If you want self-repairing, what you need to request is a partial rebuild feature. Because we can infer where a file is located on a drive, that section (or those sections) of the drive can be reconstructed from the rest of the drives + parity. That feature + the file integrity plugin should make Unraid self-repairing regardless of file system. That is probably more complicated to code on Unraid (because it's not RAID) so it will probably be a while before it's implemented. The grass always looks greener on the other side. Having been to both sides, I can tell you the other side certainly looks greener but is full of cow excretion that, if you are not careful, can explode in your face.

Indeed your tests make it clear that these WX Threadripper need some intervention for best performance. Unraid KVM is not smart enough to deal with it.

Has anyone seen this behaviour? I know if Sonarr tries to do something to a file on a unionfs mount (and because the upload location is RW and the rclone mount is RO) it will make a copy of the file from rclone mount to upload location with whatever it tries to change (e.g. a rename or a date change). The problem is there is one particular episode (and only that one!) for which the copy and the original are identical in every way (e.g. the filename, dates, the data itself, etc.). So I have no idea what Sonarr is trying to change. So you say just upload it to update the file? I did! And once it's done, Sonarr would do the exact same thing again. I think this behaviour has always been there, I didn't notice it previously because the write was done live immediately to storage before I moved to the gdrive model. The fact that it's a Doctor Who episode makes it even spookier. I'm considering just sodding it and delete it.

Please note that it may or may not resolve your issue until you find out exactly what caused the high API calls. You might want to follow other users on this topic who have multiple client_id for different purposes. Then if one API is banned because of accidental overload, you can switch to something else.

When running the benchmark, did you also set numatune to force memory load to the right NUMA node too? Your Node 0 vs Node 1-3 looks suspiciously like your VM is fully allocated to node 0 only. For VM that spread across multiple nodes, you might even want to force it so that memory is loaded evenly across different nodes. In my case, I have had to go as far as running 2 dummy VMs to load up 2 nodes to the right amount so that my main VM splits almost 50-50 across 2 nodes (and then shutdown the dummy VMs - thank goodness for CA User Scripts).