trurl

No I am saying that you should get your system share on cache if you want disk1 to spin down. Disable docker service, set system share to cache-prefer, run mover. When finished, enable docker service.

If you aren't using VMs then isos share doesn't matter and it is empty anyway. You should delete the empty appdata folder on disk1. system share exists only on disk1, it isn't empty and that is probably where you have it set to put your docker image, which is where the actual code for each of your containers resides.

Several reports of this, including just 2 posts up from yours on this thread. Apparently that update of the plugin must wait on the new release, which is anticipated.

Out-of-date Unraid plus out-of-date plugins is the likely cause.

His mappings are in the screenshot

Probably they meant Turbo Write, which only applies if you have a parity disk.

Well a button wouldn't quite be enough to suit some people in the details regarding the redistribution. And of course it would still take a long time to either clear disks or rebuild parity. As for redistributing data, have you looked at the Unbalance plugin?

https://xkcd.com/936/

I haven't actually used this feature of transmission for a while, maybe not ever with this container. I just tried it and the only way I can get it to pick up a torrent in the watch folder is to restart the container. Looking inside the container it doesn't look like it has inotify capability which I assume is what would trigger it when a new file is added.

Are you sure? Mine is in mnt/cache/appdata/transmission/watch Take a look at the file /mnt/cache/appdata/transmission/settings.json

Where is the watch folder?

I want some of that. Not sure I want it let loose on the users though.

I've had 2 Pro licenses for years but never had more than 11 attached devices on any system and my backup server is currently not used.

I have edited his post. Also @Magicaldave, I don't know what those attachments are and I am not inclined to find out. If that information can be rendered as plain text or an image then please do so in the future.

First link in the Docker FAQ:

Strictly speaking preclear isn't necessary. It is just one way to test disks. The only scenario where Unraid requires a clear disk is when adding a disk to a new data slot in an array that already has valid parity. This is so parity will be maintained since a clear (all zero) disk has no impact on existing parity. When Unraid requires a clear disk (which is only that one scenario) it will clear it if it isn't already clear. In older versions of Unraid it would take the array offline while it cleared a disk (for only that scenario) so preclear was invented to allow a disk to be cleared before (pre) adding it to the array. But Unraid now clears disks when needed without taking the array offline, so preclear has hung around as a test. There are other testing methods including the diagnostic utilities provided by the disk manufacturers as a free download. An additional bit of info, parity is not a formatted disk so it would not be formatted or cleared. And it wouldn't have needed to clear any disks in the scenario you mentioned if you had added them all at once including the parity disk.

You have a docker image mounted as shown in the next-to-last line of those "cat /proc/mounts" results. Might as well disable docker, delete the image and reclaim its storage.

👍 Thanks. Not many doing this with USB or such light hardware. Let us know how it goes.

Who are you going to pay?

Interesting. 1G RAM, no cache, no parity, but apparently running dockers. @rymalco What dockers do you run?

Maybe a typo there. 9am isn't a "how long".😉 Anyway, no need to guess. You can get the results of your last parity checks by going to Main - Array Operations and click on the History button.

Interesting. Do you have a parity disk in this setup? If so, how long does parity check take?

Have you tried another USB port on your server? Preferably USB2.

Looking at your diagnostics on another thread recently, I see your appdata is set to cache-yes, and it has been moved to disk1 and is completely on disk1 at the moment. And the same is true of your system share. Setting these to cache-only won't really help at this point since they aren't on cache and mover won't touch cache-only or cache-no shares. The working data for your docker containers is in appdata, and the code for all containers is in the docker image file in the system share. If these shares are on the array, their performance will be impacted by parity updates and they will prevent your parity and array disk(s) from spinning down. The default for these shares was probably cache-prefer. Why did you change them? To get them back on cache where they belong: Go to Settings - Docker Settings and disable the Docker service. Also Settings - VM Manager and disable VMs if they are enabled. Go to Shares - User Shares. Click on appdata and change it to cache-prefer. Do the same for the system share. Go to Main - Array Operations and click Move Now. This will probably take some time since plex in particular has a large number of small files to move After it is finished moving, set those shares to cache-only and re-enable the docker service (and VMs if they are used).

You don't need to share your disks on the network and I always recommend that people don't.