Squid

Diagnostics might tell the story

You've got the cache floor set on what I'm assuming are the shares you're talking about as 0. So, if the system does not know the size of the file that is being transferred, it will fill up the cache drive until it errors out. If it knows the size of the file, then it will first check to see if it'll fit and then decide where to move it. Set the cache floor to be the size of the largest file you reasonably expect to ever be moved to it.

Thanks. Do this: Reboot the server into GUI mode, then from Windows, log in and try and start the array. If it fails, then from the GUI do another Tools - Diagnostics. What you're saying about it getting "stuck" doesn't really make much sense as fundamentally there's zero difference between logging in via GUI mode and remotely on another computer.

Unraid does not automatically format a drive. If the drive came up as unmountable either prior to or after the rebuild process, a popup would have showed up that stated that "Formatting is never part of a rebuild process". Did you tell Unraid to format the drive? This is what caused the problem. By changing the format of the drive, it basically would've had to format the drive. (But still would have prompted you) What you want to do is take a note of all the current drive assignments, do a Tools - New Config, and then reassign the drives and substitute the original data drive back in in lieu of the replacement. If anything comes up as unmountable, STOP and then post your diagnostics and wait for a response. Let parity rebuild and then do the substitution. After that, to change the format of the drive, you first have to copy all of the files off of that drive and then once it's empty format it.

Before you revert, from GUI mode can you grab the diagnostics (Tools - Diagnostics) and post them here.

Did you

And run a memtest from the boot menu if only to rule memory possibly out.

Buy either a Seagate or Western Digital drive. They look to be a rebranded Seagate based upon the smart attributes, but are definitely running custom firmware. Not quite sure if I'd trust a drive like that

I think the issues are due to changes at ookla (could be wrong though). Either way, I'm having CA mark 2018.02.11 as being incompatible as it doesn't work at all.

I've already submitted a fix for @limetech to consider.

If the system at the file level, not torrent level knows the size of the file before it begins to be written and the share is set to be use cache: prefer, then it will automatically put it onto the array. Since this is doubtful, you'd have to create another share set to use cache no (or temporarily adjust the existing share to be use cache no) and set the file to down load to it.

@JorgeB can you see if this fixes it: (and doesn't cause any other issues - It shouldn't) Save the attached as /usr/local/sbin/mover (and give it executable permissions) mover

The diagnostics are after the reboot. Was one generated (and sitting in the logs folder on the flash drive) at time of reboot?

What flash drive error? Bread?

What is that drive mapped to? Assuming it's a share, does that share's settings include all the drives? (or in Global Share Settings) is the new drive included?

I just enabled verification on my system, and it did not get stuck for me.

Create a new thread in general support and include your diagnostics

According to a previous set of diags posted in October, mover tuning is installed. You've got to remember that with this fork of the plugin, the "Move Now" button still follows the rules you've set in it's configuration (this differs from the original plugin where Move Now always moved everything) I believe that the author of the fork has added a Move Now button (or something similiar) to the plugin's settings page which moves everything regardless of the settings.

There's some comments in the support thread about not having it cache "user" but rather switching exclusively to disks instead.

As an FYI, users with this container installed will have FCP issue a warning. Since you've got this container running with the explicit purpose to run xmrig, this warning is quite safe to ignore.

dynamix.cache.dirs.plg - 2020.08.03

No If you always use GUI mode, then set it as the default via Main, Boot Device, (click on Flash), syslinux configuration

If the share settings for appdata is set to use cache: only or prefer then it really doesn't make any difference