itimpi

There are a number of factors you have to consider: unRaid never automatically moves files between array drives. any individual file must fit on a single drive - it cannot be split between drives a vdisk is a single file as far as unRaid is concerned. It does not know that guest OS inside the VM has stored multiple files inside the vdisk. if a file already exist then it is used in its current position. If it is growing in size this can cause out-of-space errors on the drive holding the file. the Mover application ignores files that are open so if a VM is running its vdisk files cannot be moved.

I am using flash drives that I have had for 5 years plus with no problems. My experience is that if you stick with USB2 drives and avoid the tiny form factor ones they DO tend to be reliable.

The domains share is not restricted to being on disk6 - in fact at the moment it exists on disk2 and the cache. If you want to restrict it then you need to set the Include option for the share to only have disk6 listed Note that changing the setting now will not automatically move those files as it only applies to where new files are placed. Those are large files so it might be faster to move them manually to disk6 rather than relying on mover to do it? Most people WANT their VM vdisk files to be on cache as performance when they are on the array is much lower due to the overheads of keeping parity updated.

This is mentioned in the 6.9.2 release notes.

These look like files for a VM? The VM must not be running if you want them to be backed up. There is a plugin specifically targeting backing up VMs - it might be of use to you?

The 2 shares I mentioned no longer exist on the cache which is good. What share contains files that you want to be moved to the array that appears to not be happening? Y/u could try turning on mover logging under Settings -> Scheduler to possibly get more information although you do not want to leave that option permanently set as it can be verbose and fill up your syslog. If a file is open or already exists on the array it will not be moved.

The diagnostics show that you have 2 shares with names of the form C——S and B——-p which have files on the cache and the array. However they have a Use Cache=No setting, and if you read the help built into the GUI you will see it says that if files get created for any reason on the cache which logically belong on the array they will stay there with the ‘No’ setting. You need a ‘yes’ setting for mover to take any action on them.

I do not think that is enough to be able to reliably update via the GUI. If you want to update via the manual method: connect the flash drive to a PC/Mac make a backup of the flash drive in case you want to be able later revert download the zip of the release you want to use from the unRaid download page extract all the bz* type files overwriting the ones on the flash drive It is probably worth pointing out that as long as you can get hold of the relevant zip file you can use this method to go to any particular release

Yes. If there are any issues then emailing Limetech normally results in quick resolution. Just make sure you have a backup of the old one before proceeding (or at least the 'config' folder off the old one as it contains all your settings). The documentation is also accessible via the unRaid web site. It is progressively being improved so and it is often easier to find what you are looking for there (as it is more structured) than trying to search in the forum.

Does the information here help? This is from the online documentation that can be accessed via the Manual link at the bottom of the unraid GUI.

Yes, just add them as you need them.

Because to calculate the contents of a particular sector on the parity drive, then the corresponding sector has to be read from ALL data drives to allow the contents of that sector on the parity drive to be calculated.

The only time I had such a problem it turned out to be on my Windows client side in that it’s network link failed under load.

If you do not have a cache drive then you need to reconfigure them to not use ‘mnt/cache’. I do not see how that could have worked on any unRaid release with no cache drive present as if you do not have a cache drive that location is in RAM. In such a case you should use /mnt/user/appdata as that allows files to be on either the array or a cache drive.

This is normally recommended because then at the application level you do not have to worry about what physical drive contains the files and they can be moved around without having to change application settings. It does not mean that you WILL have files on all the drives - that is controlled by the Use Cache setting on the share.

As I mentioned I think you will find it is a quirk of the way radarr is interacting with the underlying Linux system on unRid and that is resulting in the User Share system being bypassed and the target folder ending up on the same drive as the download folder.

Something strange going on - I would normally only expect formatting to take a few minutes and not put much load on the system. whether running the pre-clears in parallel was causing some sort of contention I have no idea

I understand that device only has 1GB RAM and as was mentioned you really need 4GB or more to run unRaid and I think you need at least 2GB to successfully boot unRaid.

I believe it could be done from the command line on unRaid using gdisk for the partitioning and then the relevant mkfs variants for formatting. Not exactly user friendly though As you say much easier to do on another platform with friendlier tools.

You only ever really want mover logging enabled if you are actively investigating a problem with mover not behaving as you expect. The rest of the time leave it disabled.

Those look sensible. Once you get your head around the concepts then it is easy to later make changes if your needs change. As to the frequency at which mover runs then it really is up to you and your usage pattern. The key point is to run mover at a time that has minimal impact on your use of the system and it does not have so many files to move that it is still running when you want to start using the server for other things. If you leave your server powered on 24x7 then the default of every night at around 3:30 is as good a time as any. If you have plenty of space on the cache drive for the amount of new files you accumulate then less frequently is fine. You should set the Minimum Free Space value for the cache and for any share to be greater than the largest file you expect to have. That way unRaid will transparently switch between using cache and array without failing transfers due to insufficient space for a particular file.

I would suggest that you give examples of the paths to such files and provide a copy of your system’s diagnostics zip file so we can see how this relates to your chosen settings

No - that is correct behaviour. If you read this section of the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI it explains why. basically ‘turbo write’ trades off the being able to keep drives spun down wherever possible against better performance. However you still do not get some of the additional speed other RAID types can achieve using striping techniques because of the fact that files and parity are restricted to existing on single drives. No modern NAS is constrained by the CPU power as they all have more than enough to handle parity calculations. They are nearly always constrained by the I/O rates the drives can support and the I/O pattern that arises from the mix of capabilities to be supported.

Glad you think so While this is fresh in your mind any feedback on ways to make this clearer the first time around that might occur to you would be welcomed. This is a common area in which users get confused.

This is quite typical. By using /mnt/cache you are referencing the physical drive directly and bypassing the User Share system. However since each top level folder on any drive is considered part of a User Share then files will also show up under the 'appdata' and 'system' shares. You always have two ways of viewing files - directly by going to physical drive and a separate logical view at the User Share level that gives an amalgamated view across drives. They are still the same files.