itimpi

Do you have any free connections for mounting additional drives? You could format and mount the new drives using the Unassigned Devices plugin and then copy data from the existing drives one at a time across to new drives. At the completion of this you could then use New Config tool to create a new array of just the new drives taking advantage of the fact that Unraid will leave there contents intact as they are already partitioned/formatted correctly for Unraid and then add the new parity drives to build parity based on the new set of data drives. The advantage of this is that you keep the old drives and their contents intact until you have the new drives up and running.

Mover will never overwrite files so if a file exists in two locations you need to manually decide which copy to keep and delete the other one.

If you click on the orange thumbs down icon and select the Acknowledge option from the resulting menu then you will only be prompted again if it increase. Note this value never resets so you can only stop it increasing.

But what if the share is on a mixture of file systems only some of which support compression.

This particular one is already easy to do use the combination of the Unassigned Devices plugin to manage mounting the drive outside the array and the Dynamix File Manager to handle the transfer. (unless I have misunderstood what you mean by this idea).

This would then be a ZFS specific setting, not a generic setting that can be applied to the main array so it would only make sense for exclusive shares that are on ZFS pools. If it was to be implemented I would think it was easiest to do at the disk/pool level< not at the share level.

As far as I know the only requirement is that the share in question only exists on the pool. I have seen no mention of the pool not containing data from other shares. I think internally it is just Unraid automatically treating /mnt/user/share as if it were /mnt/pool/share bypassing the fuse layer.

Since even 1 error is a problem then I guess you have identified a probable cause of your issues.

One point that does not seem to be mentioned is whether you need to keep all the data online and accessible the way it is currently during this process as that might make a difference to the answer. Also since with that amount of data will take a significant time to migrate do you have any views on how you would view speed v availability of the data.

This is incompatible with the basic Unraid assumption that in the main array each drive is a self-contained file system that can be read by itself outside Unraid. If you want striping then you should probably be using ZFS pool for this purpose.

For disks to suddenly appear under Unassigned devices when they should be part of the array, then that means they temporarily dropped offline, and then reconnected with a different device Id. I would carefully check cabling SATA and Power to the drives in case there is an intermittent connection somewhere.

You might find this section of the online documentation to be of use.

Even worse as the Linux level is not aware of User Shares it might try and overwrite the copy on the cache with itself which ends up truncating the file to 0 length.

I do not see how this could be implemented as compression happens at the file system level, and User Shares are an abstraction layer above that and are not aware of the underlying file system. Any compression would therefore need to be set at the disk level.

that could go wrong and lead to data loss as you are mixing a physical device and a User Share in the same command. The target needs to be of the form /mnt/disk#/share where # represents the disk you want it to end up on.

You can make the changes without stopping anything Having said that if you are on the 6.12.x releases you can get the same performance benefit without making any changes to paths by doing the following: Make sure that Permit Exclusive shares is enabled under Settings->Global Share Settings Set the pool to be primary storage with no secondary storage (equivalent to Cache Only in earlier releases) make sure that all files for the share are on the pool. You will now be able to activate Exclusive mode in the share settings. with these changes you get the same performance whether you go direct or via the User Share path.

The support on this forum is primarily from users. You can contact official Unraid support via email.

A point to remember is that parity had none of your data - it just has the information that is required to rebuild the contents of s data disk if that fails. In that sense parity is probably the disk you should panic the least about because as long as all the data drives are OK it’s contents can always be rebuilt from them.

As I have been reading this thread, if you currently have files on a cache disk then the % displayed will be relative to that pool? If mover then moves the files to the array so there are no files longer on the cache pool I assume the % displayed will now change to be relative to the smallest array drive that is part of the share? Assuming that is correct then I can see how users will get confused when this % value appears to change without them making any change.

The syslog in your diagnostics shows: Jul 18 17:54:47 BEAST kernel: nvme nvme5: Device not ready; aborting reset, CSTS=0x1 Jul 18 17:54:47 BEAST kernel: nvme nvme5: Removing after probe failure status: -19 This looks like some sort of hardware related error. I would suggest making sure everything is firmly plugged in.

That speed seems fine to me. Not sure what you expect. Unfortunately copying large amounts of data simply takes a long time

Quite likely I guess

What exactly are you trying to achieve? If you use a different flash drive with a different GUID then it will not be blacklisted.

Are you sure that you did not have 2 flash drives and the system is now using a different one. I can think of no mechanism that would otherwise describe the Unraid version change you mentioned.

No. Once a flash drive has been registered to Unraid and the licence then moved to another flash drive then the original is blacklisted and can never again be used to run Unraid.