itimpi

You have to decide where you want it to end up. Most people want it on the array in case they lose their cache for some reason. This would probably best be set to No (as it is at the moment) to force the backup to go direct to the array.

If you read my previous reply you will see I am recommending against using No for this.

you almost certainly want all the working folder for qbittorrent set to either ‘Only’ or ‘Prefer’ to keep those files on the cache for efficiency. You then want the final target folder to have the Use Cache setting of Yes to ensure mover later picks up the files and moves them off the cache to the array. Part of the problem was that originally the Use Cache only had settings of Yes or No. When more sophisticated behaviour was introduced the values of ‘Only’ and ‘Prefer’ were added. Nobody could come up with a better single word than ‘Prefer’ to describe how that setting works. If we were starting with a clean sheet we would probably invert the meaning of the Yes and Prefer settings, but there is to much legacy around to do that at this stage without massive disruption.

Changing the setting to Yes WILL make it work. If you carefully read the help for that setting you might work out why Yes is needed. The effect of the different values is not immediately obvious. The problem you are encountering stems from the fact that qbittorrent is working at a level where it is falling foul of the way moves are handled at the Linux level and is thus managing to by-pass the User Share system creating the folder on the same drive as the downloads folder.

You are correct in that it is not possible to include only the cache disk for a share. However if all the files for that share are on the cache and you set `use Cache=only then files will never get put on the array. If you instead set Use Cache=Prefer then files will only be stored on the array if there is not room on the cache. For your Media share then Use Cache=Yes is almost certainly the correct setting. You might want to read the help built into the GUI for a good summary of the effect of the Use Cache setting. There is also more detailed write up here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI.

What share are you expecting files to be moved for? You have several files set to Use Cache=No with files on the cache. if you turn on the Help in the GUI for the Use Cache setting you will see it says with that setting mover will take no action. If you want files to be moved from Cache to array then you need Use Cache=Yes as the setting.

OK. I would suggest that you enable mover logging under Settings -> Scheduler; try the move again and then you are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post.

Experience of many users has been that USB2 has proved far more reliable for booting and running unRaid. Why is not clear as there is no theoretical reason why later versions of USB should not work. It could be that BIOS’s are better at handling USB2 or simply that USB2 is less demanding on the hardware. Since there is no significant performance advantage to using USB3 (as the flash drive is rarely accessed after initial boot) we always recommend using USB2 if you can.

if I understand correctly what you want you achieve this by having the ‘archive’ share with a the Use Cache setting set to ‘Yes’. The whole idea is that files in shares with this value set are initially written to the cache and automatically transferred to the array when mover runs (typically overnight). It is transparent to anything referencing the /mnt/user/archive path (or its sub-folders) whether a file is physically on the cache or on the main array.

Not sure what tutorial you are talking about? I think it might be worth getting the steps involved in setting up such a VM into the VM section of the official documentation? The one thing there is no workaround that I know of is the requirement to use a genuine (licenced) flash drive for each running VM.

What are using to do the downloads and (potentially) the move to the final location? I suspect whatever you are using is by-passing the User Share system and simply creating the folder on the same drive as the downloads.

It is normally recommended that scheduled parity checks are set up as non-correcting. That rationale is that if you have a drive mis-behaving and producing read errors you will not end up corrupting parity inadvertently. Ideally you only want to run a correcting check when you think there might be some errors to correct and you know why they happened.

Thanks for the feedback. Nice to know there is no issue outstanding that I should be looking at with any sense of urgency. The unplanned checks I think should be OK as since it was a new feature it got a bit more testing in the recent releases than previously existing functionality.

Those messages definitely indicate that the system is having problems reading from the flash drive. I would suggest that at the very least try plugging it into a Windows/Mac system and let that check the drive. Sometimes simply rewriting its contents can help. Maybe even just downloading the zip file from the unRaid site and extracting all the bz* type files overwriting the ones on the flash drive might be sufficient. If the flash drive is about to fail do you have a backup of it? In particular the ‘config’ folder and its settings as that contains all the user specific settings and the licence file.

This normally means the disk dropped offline and then came back online with a different ID (the diagnostics would confirm this). How is it connected - this is not atypical of USB connected devices which is why USB is normally not recommended for array drives.

On neither server type is the CPU likely to be the performance limiting. UnRaid has some design objectives that are not there in RAID5 systems: Not all drives need to be spinning when writing files to the array. In fact on a typical system on the target drive and the parity drive need to be spinning. Disks of mixed sizes can be used, and all parity information is on a particular drive. each disk has a self contained filing system. This means any individual file must reside on a single drive and thus striping techniques cannot be used. Any single file can never be read faster than a single drive can deliver. the above list is not exhaustive but gives an idea that the objectives are different between the two approaches. The link I gave describes what I/O is involved in writing to a an unRaid parity protected array and it is very different to the I/O pattern for a RAID5 array. The net effect is that updating a sector on the unRaid main array involves more I/O operations plus a rotational delay that is not present on RAID5 systems meaning that performance will never get even close to a RAID5 system using the same disks. If performance is your main objective then unRaid is not the best system to use. However for most home users it’s other attributes mean it suits them well and performance is sufficient for their needs.

The way parity is handled in the two cases and the resulting I/O is completely different. A description of how unRaid actually writes with the resulting I/O can be found here in the online documentation accessible via the ‘Manual’ link at the bottom-m of the unRaid GUI.

If you did a format then that would create an empty file system and update parity to reflect this. When you try and format you get a big warning telling you that format is not part of a rebuild. if you still have the old disk intact it should be possible to mount it using UD and then copy the files back to the array.

What do you mean by this? There is no format step as part of a rebuild.

Whether scheduled parity checks are correcting or not is set under Settings -> Scheduler. For Manual checks is set by the Correcting checkbox next to the Check button on the main page. The automatic checks after an unclean shutdown are always non-correcting.

At the moment the Use Cach setting = Yes which means you want it initially be written to the cache and later moved to the array. The Help built into the GUI gives a good summary of how the settings operate. the way to proceed to get it on the cache is: disable docker/VMs services if they are enabled (as files open in these services cannot be moved) change the Use Cache setting for the ‘system’ share to ‘Prefer’ manually run mover from the Main tab to get it to move ‘Prefer’ type shares from array to cache. When mover finishes you can re-enable the Docker and/or VMs services iyou use. (optional) change the Use Cache setting to ‘Only’ to say files for this share can never be written to the array.

That is normal as until the rebuild finishes the parity is deemed to not be valid.

What was the issue that was reported. I did not spot anything in the diagnostics.

you could use Tools -> New Config and select the option to retain all the current assignments. Then when you return to the Main tab tick the “Parity is already valid” checkbox before starting the array and unRaid will promptly try and start the array without rebuilding parity. This will not however guarantee that parity IS valid, and you would need to run a parity check to confirm it is. Fixing an unmountable drive is a different issue and is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI. I believe there is wiki article that goes into even more detail but I do not have its link to hand.

The memtest that comes with unRaid will give those symptoms if you are booting in UEFI mode. If you want a version that works in UEFI mode then you need to download it from the memtest web site Simply fixing a connection/power issue is not sufficient to clear the disabled status. You need to rebuild the parity to clear it.