itimpi

Are these uploads happening in parallel? If so this problem can easily occur as the check for free space only happens at the point the file is first created (when it has 0 size), and in such a case one needs to have the free space for the cache pool to be enough to allow for the number of files that could be uploaded in parallel to fit. Have you set the Minimum Free Space setting for both the cache pool and the User Share in question? It might be a good idea to post your system's diagnostics zip file in your next post in this thread to get more informed feedback as it will allow us to see the settings your are using. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

Not sure if the screenshot shows the drive has failed. Normally the section that really matters is this one: SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 26203 - # 2 Extended offline Completed without error 00% 26117 - That shows the last extended test completed without error. You should probably now run another one to see if it still passes as that tends to be the best indication of drive health, and failing that is almost invariably accepted as a reason for a RMA (assuming the drive is still under warranty).

Have you restarted in Normal mode to check that the drive now mounts and seems to have its data intact? Any files/folders for which the repair process cannot find the correct name will have been put into a lost+found folder on the drive.

The configuration (and licence) is on the flash drive so if you are using the same flash drive you should have the same configuration. The fact you say the licence file was missing suggests you may not be using the same flash drive?

The device name can vary according to the Unraid release (and whether encryption is used). It is better if you run it via the GUI as that will automatically select the correct device name.

The only mapping you have is to /mnt/user which is where User Shares are mounted. Local drives mounted by UD appear under /mnt/disks and remote shares under /mnt/remote. If you want Krusader to be able to access either of these then you need to add volume mappings to support this.

At the moment there appears to be something writing to disk16 which will be slowing things down

If your parity is not valid then I do not see much option other than to temporarily have the old controller present so that you can mount the drives and then copy their contents to another drive that is on the new controller (probably one drive at a time).

It used to always default to 0 (which caused its own problems), but I think it now defaults to some percentage of the drives used which most of the time is a better value, although as you found can still cause issues if you are not aware of the setting.

As I said you need to stop whatever is writing to disk6 to determine if that is the reason for the slow speed or whether it something else.

As far as I know that combination follows the Limetech guidelines. I expect @JorgeB will chime in if there is anything obviously wrong.

Definitely a good data point. Normally crashing during a sync is most likely to point toward power/PSU issues as that tends to be when the system is most heavily loaded but it could be a complete red herring in this case.

The increase in macvlan related issues seems to be a by-product of the kernel version that Linux is using combined with the specific hardware combinations. I assume the Limetech are trying to finally resolve this issue but not that hopeful as it has gone for a very long time but it is always possible that a newer kernel in a future Unraid release will help. However I mentioned plex as that can crash the server even when you do not have macvlan issues. I think in particular it occurred with a recent beta release.

Then the issue could be with the dockers involved. Plex for instance in some of its releases has a history of bringing down the server.

Nice idea but I have a feeling it will not work because Unraid does not support the required protocols (I would love to be proved wrong though). Even if it does not work now maybe someone could work out what Limetech needs to add to Unraid to make it possible,

Not true. I think it is possible knowing what files they were might give a strong clue as to what application area is involved.

The other big thing that btrfs provides in pools is the ability to add drives to a pool at any point, and they can be of mixed sizes rather like in the main array. ZFS is far more restricted in the expansion capabilities of a pool. The main thing I see zfs bringing to Unraid is performance advantages which for many people seems to be an important consideration.

Yes - but I wanted to see which file it was.

How far into the parity check is it? Looking at the disk speed graphs disk3 has some very slow sections and since at any point the check speed is determined by the slowest drive I would expect slowdowns while in that section. Also some of the other drives are slower than I would expect. Having said that the diagnostics show that there is a lot of write activity on disk6 so that is also going to badly slow down the parity check (the activity shows up in the system/loads.txt file in the diagnostics.). In practice that is the most likely cause of the slow speeds.

I did - they showed up with the right side clipped off

It is quite normal when switching from a RAID controller to a different one for the drives to not be recognised when the two controllers do not present the drives identically to Unraid. It is only when both old and new controllers are simple HBA's that it is painless. I 'think' that it is possible to go through the rebuild process one drive at a time to fix this as long as if you remove a drive the 'emulated' drive shows the correct content, but not sure (particularly as you have encrypted drives). However this is not going to work without the parity drives. Some other user such as @JorgeB might be able to chime in on this.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field. Having said that you seem to have a macvlan related crash which will eventually bring down the server. As mentioned in the Unraid Release notes if you want to continue using macvlan for Docker networking then you should disable bridging on eth0. The alternative is to switch docker to using ipvlan networking.

Both the links you posted go to obsolete documentation. The online documentation is accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release. The section on replacing disks is here. You will need to upgrade parity first as no data drive can be larger than the smallest parity drive.

normally basic anonymisation is automatic.

What HBA did you have in the old system?