itimpi

You probably do not need to power down, but Unraid is not hot-swap aware and it will not let you change any Disk assignments with the array started.

Unraid will only disable a disk if a WRITE to it fails. As was mentioned CRC errors are connection related and are very rarely a genuine disk issue. They only cause a retires to occur and as long as a retry succeeds then things continue otherwise unaffected. One thing to be aware of with CRC errors is that there is no way to set the count back to 0 - it can only increase, so if it stops increasing after taking some rectification action that is all you can expect.

There is no magic answer to give for the size of a cache drive (if you even bother with one at all) as it dependent on an individual’s usage pattern. If you are going to use it in its role of buffering writes to the main array then it should have at least enough space to handle a typical days worth of new files on the basis you will let the mover application run overnight to move file to the main array. Any requirements for applications run as either docker containers and/or VMs are over and above that.

I assume that at the moment disk1 is being emulated? If so can you see its contents OK? If so then you want to use the Parity Swap procedure which is specifically intended for the case where you want to upgrade to a larger parity drive and use the current parity drive to replace a failed data drive. If not then we need more information before we can advise on the best way forward.

What you are describing is not atypical. 2 drives (1 x parity + 1x data) is a special case - as soon as you add a second data drive then the overhead of keeping parity in sync becomes more significant (it does not continue to go up as more drives are added). You may find this section of the online documentation useful in explaining why. It is likely that enabling "Turbo Write" as described in the link will give you better performance but it will still probably not reach raw drive speeds. Another alternative is to use a cache drive to that the initial writes go to the cache and then files are later moved to the array in idle periods (i.e. overnight).

Do those diagnostics cover a period where the problem is occurring? They look at though they may be just after rebooting. If not then I have no idea why you are seeing what you describe - not something anyone else has encountered as far as I know.

The docker.img file is created (if not already present) when the docker service starts as something to contain the binaries for apps. Think of the docker container as being the binary files for an app and the backup contains all the apps working file.

Is is normally recommended that you do NOT use the cache drive during initial data load as it typically just slows things down unless all the files you intend to copy in a day will fit onto the cache drive (so that mover can move them (comparatively slowly) to the main array overnight) . Adding files after the initial load can better use the cache drive as then files are only moved to the array during idle periods (typically overnight). For this purpose a HDD may be sufficient. However if you intend to run docker containers or VMs then they gain significant performance benefit to having them hosted an an SSD rather than the main array.

It will be. you do not actually say what you intend to use the cache drive for? That might affect your decision on the best way forward. Also you do not mention if you intend to run with or without parity.

That is true, but why do you need to use preclear if all you want to do is reformat the drive to a new file system? Unless you suspect the drives might be failing so you need to stress test them it seems like a waste of time and puts extra wear on the drives.

If you want any sort of useful feedback you should provide your system's diagnostics zip file (obtained via Tools -> Diagnostics) covering a period when you are experiencing this issue. It sounds as if there may be some sort of hardware issue but that is just a guess without something to wiok with.

It is always (if you can) worth trying to see if Unraid will boot off the flash drive on another machine.

No need to unassign the drives. The procedure to follow is covered here in the online documentation you can access using the ‘Manuak’ link at the bottom of the Unraid GUI.

Have you checked the BIOS settings - it is not unusual for a BIOS to spot a change and to try and be helpful and reset the boot device. The symptom you describe is what you get in such a case. you can still make a backup as long as you can read the ‘config’ folder on the flash dtive. That is where all the settings specific to your system are stored.

That message is quite normal and very rarely leads to data loss - and despite its ominous wording even when it does it only affects the last file written. You need to try again but add the -L option.

The Default iso storage path looks wrong - the location /mnt/ is not a valid location as that would be in RAM

It would depend when the folders ‘Bob’ and ‘Fred’ were created. If they both got created initially on disk1 then all subsequent content would also go to disk1 with a Split Level setting of 1.

That would mean that once a folder has been created under the top level, all files for that folder (and sub-folders) are constrained to the drive where the folder was first created.

The extended test reads every sector on the drive so I would expect something like 1 - 2 hours per TB.

What do you have for the Split Level settings on the relevant shares? Split level will over-ride Allocation method if they conflict.

I wonder if the new feature in 6.9 beta 35 to allow extra modules to be loaded will allow users to add this module?

No - Unraid does not care where it is plugged - just that it is. Unraid is largely hardware agnostic. it surprises me how many people are finding USB3 drives to be unreliable for prolonged use (in theory they should ‘just work’) but maybe that is just the current state of the technology.

Unraid will not automatically move files around. you can determine using the Allocation Method setting on shares how new files should be split across drives. The default is “High-Water” and you might want to read up on exactly how that works. Note however that if you have set the Split Level setting explicitly this can over-ride allocation method.

It could just be a case of the drive dropping offline for some reason and the drive is actually fine. If you post your system’s diagnostics zip file (obtained via Tools -> Diagnostics) in its current state we should be able to determine if this is the case. If it has dropped offline, then diagnostics taken after power cycling the server should give a better idea of whether the drive really has problems.

Optional but I would start the array in normal mode as that would at least tell you whether the disk now mounts OK, and gives you a chance to see how successful the reiserfsck was in restoring all data. You should not try to access the disk running the SMART test while it is running as that can abort the test.