itimpi

The easiest thing to do is to simply do it via a User Share rather than a disk share (which sharing the cache is) as then it does not matter if a file is on the cache or array.

No idea on final version, but there has already been comments that rc3 will have the 5.15 kernel (or later I guess).

With basic Unraid you would have to start again. Normally all array level operations need to be restarted from the beginning if they do not run to completion before stopping the server. However if you have the Parity Check Tuning plugin installed and you are on Unraid 6.9.0 (or later) and the following conditions are met: you have set the option to resume array operations next time array starts in the plug-in settings [EDIT: I have been thinking of making this the default behaviour so that the user does not need to explicitly request it - any feedback on this idea is welcomed] you pause the sync if you want although this should not be necessary. you successfully stop the array (so that you will not end up with an unclean shutdown). then you can shutdown the server and when you next boot the server (presumably after the power is OK) the parity operation should be resumed from the point it had already reached when the array is started. Note that I used the word ‘should’ because although I have tested what I think is this scenario on my development environment I have not yet had any feedback as to whether it has successfully (or not) been handled in a real world situation. If it does not work for any reason then it can be restarted from the beginning so it does not hurt to try. I would love to get some feedback from anyone who has used this feature. EDIT: If anyone finds themselves about to use this feature in anger I would be very grateful if they could also set the ‘testing’ mode of logging in the plugins settings and then send me their diagnostics/syslog after restarting the array so I can check if the restart was handled as expected.

It might be worth trying a ‘cp’ command rather than rsync to see if this changes the symptoms in case it is something to do with the way rsync operates.

You several time refer to mnt/* without a leading / character. That makes it a relative path rather than an absolute one and what it is relative to is context sensitive. Could this be the cause of your issues?

Yes , but with that value no file must be as big as 1GB or you will still have problems as Unraid does not take the size of a file into account when selecting the location to store it. Unraid never switches to another location once it has selected one for a file - instead you get out-of-space errors when the file does not fit.

I guess that is OK as it is a persistent location.

Click on the drive on the Main tab and select the Scrub option.

Have you explicitly set the Mnimum Free Space for the cache as described here rather than the one at the share level that applies to array disks.

You will need to store the scripts on the flash drive and recopy the scripts any time the system is booted as that location is in RAM. You will also have to add a command to set the execute bit in the permissions.

No. With 6.9.0 you can have multiple pools (with user specified names), and any of them can be set to cache a share. Under settings -> Identification.

Looks like it has a old firmware version, so you might want to consider updating it to the most recent version.

Limetech never gives predicted release dates

You should set the Minimum Free Space setting for the cache (accessed by clicking on it on the Main tab) to be more than the largest file you expect to copy. When the free space on the cache falls below this value Unraid will start by-passing the cache and write new files directly to the array. This should stop the cache getting so full it causes problems.

Safe Mode in Unraid (it is one of the options on the Unraid boot menu). Safe mode suppresses loading of any plugins.

If you really have no internet at all then you may have a problem as that would mean you cannot even email Limetech to get them to issue a replacement licence manually. In terms of having a backup I would suggest that every time you make a configuration change of any significance then click on the flash drive on the Main tab and select the option to download a backup as a ZIP file so that you have one locally.

Y You are getting continual resets on disk4 which suggests a cabling issue with the drive.

The Parity check Tuning plug-in does not take account of other plugins running at the same time. There is a level of reduced performance in the parity check speed while the backup is running, but probably not enough to really matter.

It could be the card. Another possibility is unreliable power, particularly if you are using splitters as that can cause intermittent connection issues due to vibrations.

Drives always get slower as the heads move towards the inner tracks. I believe that this is due to the tracks being shorter and thus having less sectors per disk rotation.

Did not spot nothing obvious in the diagnostics. The symptoms suggest that the drive where the appdata and/or system shares are located might have problems. Looking at the diagnostics appdata share seems to be on disk3 and system on disk1. If that is what you expect I would suggest running a file system check on these drives.

That is expected! You will only get a folder for that share on the pool if there are any files for the share currently on the pool. It will get created on the pool when copying a file to the share if the share settings indicate this is appropriate. It can also be removed from the pool by mover if all files for the share have been moved to the main array. Normally User shares are created via the Shares tab as that is the only place you can link them to a pool. The fact that a User Share can also get created automatically by creating a top level folder at the right location is a quirk of the current implementation of User Shares and not something you should rely on (although you also want to be aware it can happen).

Occasional CRC errors is not really something to worry about. It is when the occur with some frequency that you need to do something about it.

You are likely to get better informed feedback if you post your system's diagnostics zip file.

Yes - that is the big advantage they have over UD devices Have you even tried to set up a share and told it to use a pool? Your screenshot of the shares tab suggests that none of those shares have been told to use a pool for caching purposes