itimpi

You need to contact Limetech by email (Contact link at bottom of forum) as they will not necessarily see any forum messages.

It is part of the User Contributed content section of the wiki. The Official Documentation part of the wiki has UnRAID_6 as part of the URL.

That was the whole motivation for developing the Parity Check Tuning plugin in the first place. For many people performance during prime time is very important so off-loading parity checking to only run outside prime time is worth it despite the fact that it now takes longer to complete the parity check.

I have a 16 port LSI but is more than twice the price of an equivalent 8 port one. In my case I needed 16 ports and being able to do this using only a single PCIe slot the motherboard was worth the extra expense.

Unraid can report unrealistic speeds in the history if you run the check in increments as it does not allow for the pauses but assumes the whole check was run in the last increment. If the check completes the Parity Check Tuning plugin patches the history file to what was really achieved.

If you set up the Wireguard VPN that is now built into Unraid that would allow you to securely remotely access the Unraid server (and thus its GUI to start the array) even without the array started.

How much RAM do you have? Many people set the Plex transcode location to be in RAM

Parity2 uses a different algorithm to parity1 to calculate its contents so they are NOT mirrors. Unlike parity1, the algorithm for parity2 includes disk slot number as one of its inputs. I am not sure if Limetech have ever given details of the exact calculations that are used other than to say they are more demanding on the CPU than the ones used for parity1.

YES. The whole idea of stopping those services is so that they are not holding open files you want mover to act on.

Yes, internally UnBalance uses disk-to-disk moves.

Just to check the obvious - I assume you have actually formatted the array disks after adding them to the array? if you need help then please attach your system diagnostics zip file (obtained via Tools >> Diagnostics) to your NEXT post do we can get a better idea of what is going on.

At the moment when you make changes to any share this results in the Samba service being restarted which momentarily disrupts activity on all shares. There is a feature request outstanding to instead tell Samba to re-read its configuration file rather than restarting the service to avoid this. I have no idea if the feature request is being actioned, and if so what the ETA might be.

You can effectively do the same thing directly in Unraid with less effort by initially assigning all drives as data drives and starting the array. The parity drive can then be identified by the fact it is the only unmountable drive. You now use Tools >> New Config (with the option to retain current assignments to minimise chance of an error) and return to the Main tab to Unassign the now known parity drive from the data drive slot and assign it to the parity slot. You can move around the other data drives at this point if you want. Start the array to get back to normal operation.

You are mis-interpreting the FCP message. It is telling you that those files exist on the array disk2 and on the cache and have nothing to do with the fact you added a second cache drive. Those are files for supporting the Docker and VM services. The question is which copy is actually the correct ‘live’ one? Normally the copy on the cache takes precedence but iyou might want to check that is the one to keep in your case. Once you have identified the correct one to keep the other copy should be deleted.

It is not clear to me why Plex is crashing unless there is something I am missing. If you have 20GB as the Minimum Free Space for the cache why is it “Full” as once that limit is reached files should start going directly to the array (assuming you have not explicitly sent them to the cache thus by-passing the User Share sub-System). Is Plex still building its library so is using an increasing amount of cache space?

Are you saying you are transferring a single 400GB file? If so this will start writing to the cache and then error out when it runs out of space as Unraid never switches drives once one has been selected as the destination for the file (Unraid does not know the size of a file at the point where it makes a drive selection).

Edit the title on the first post in the thread.

I would suggest enabling mover logging, starting mover and then getting new diagnostics so we can see what is going on. Be aware, however, that the mover logging is not anonymised unless there was a recent change made.

Mover will not move any files that are open, so if you have any torrents that are downloading or seeding they will be stuck on the cache. Also many people have internet links that are fast enough to let them download faster than mover can move files to the array. If you want to get a better idea of exactly what mover is doing you can enable mover logging.

I missed the fact the parity drive failed during rebuild . if the original 1TB drive is still intact then it might be best to assume the rebuilt drive2 has nothing useful on it? You can check if the 1TB drive mounts under Unassigned devices and appears to contain the expected data.. In which case the thing to do will be to get the array back into a useable state with valid parity and then reformat disk2 to set it back to empty and copy the data from the 1TB drive.

I assume that this is a drive mounted via Unassigned Devices? Have you made sure that the mapping in the Krusader docker for ‘transfer’ is using one of the ‘slave’ options for the access mode? Other than that I have no idea what could be going wrong it might be worth rebooting the Unraid server to see if that rectifies things. If none of those suggestions help I can only suggest posting new diagnostics while the problem is occurring to see if they give a clue as to what is going on.

No. Many people do not realize that XMP is an overclocked setting and thus the question.

The screenshot IS the advanced view despite it saying Basic View at top right . I guess that leaves outstanding the question of whether you can get out of advanced view

Yes - that is the correct procedure. The only difference is that in this case it will be building new parity based on the data drives rather than trying to rebuild the data on to an array data drive. There should be no corruption unless you already have corruption on the data drives. Parity will be built to correspond to whatever is already on those drives.

Are you sure that the files are moved to the cache drive? If so they should no longer be present on disk1. Mover cannot move open files so you need to have stopped the docker and VM services before invoking mover as they will be holding files open.