itimpi

Yes, in Maintenance mode the array disks are not mounted so there is no way new files can be written to them.

If you are not sure of the state of the drives it is probably a good idea to do a preclear to test them out before trying to use them in Unraid. Although you are correct in that the rebuild would write every sector it can be awkward to try and recover if the rebuild goes wrong due to issues with the new disk(s). It is much easier to handle discovering this during a preclear.

The SFF <-> SATA type cables are ALWAYS directional I believe as the internal wiring is different. Very confusing as they look identical for the two different directions.

I think we need to know more about your hardware to give any view. Posting you system’s diagnostics zip file (obtained via Tools -> Diagnostics) might also help with providing advice.

Has the cache drive been formatted? You should attach your system's diagnostics zip file (obtained via Tools -> Diagnostics) to your next post to get any sort of informed feedback.

Yes -you can do that. however it is worth pointing out that is not ‘files’ that are being tracked but physical disk sectors as the rebuild process has no understanding of file systems.

exFAT is not a standard Unraid format so those messages probably relate to an exchangeable device you have plugged in as an Unassigned Device. Whether they are affecting performance I have no idea but they might be so probably worth unplugging any such device to see. In terms of speed moving lots of small files via mover can be slow due to the housekeeping overhead associated with each file. As you noted Plex is prone to creating lots of files that fall into the category.

No problem. Unraid recognises drives by their serial number (and also tracks the size as a confidence check) and not by how they are connected. You can safely move drives between SATA ports if needed and Unraid will still recognise them in their new positions. One point to note, however, is that if you do not need the space it might be worth not plugging the 1TB drive in yet. Each drive added is another point of potential failure and also a consumer of power.

What version of Unraid are you using? Newer hardware (particularly that with 2.5Gb NICs) will likely require the 6.9.0 beta release to have drivers for the NIC.

I assume by "Unmounted" you mean you changed the drive to "Not Assigned" before restarting the array? If the 2TB drive was then showing as "missing" you should be OK and it was only the "emulated" drive that was formatted. If so you should be able to mount the drive externally to the array using the "Unassigned Devices" (UD) plugin. Assuming you want this drive to later be used in the array you can now copy all the files off it (to the array?). When you later attempt to add it back into the array to take the place of the "missing" drive Unraid will rebuild it (erasing any current contents) to whatever is showing as on the "emulated" drive as all the rebuild process does is make a physical drive match the emulated one.

There is also a setting for the Minimum Free Space for the cache drive under Settings -> Global Share Settings.

It is an option on the Tools tab. you can also get them by using the ‘diagnostics’ command from a console session.

What you want should work fine. The potential problem only arises when you mix /mnt/user and /mnt/disk (without an ‘s’) or /mnt/cache type paths in the same command. When using unassigned drives you are fine.

That screenshot shows that sabnzb is downloading to a folder called '32400' that is internal to the docker image. The /download folder should be mapped to a location that is external to the container.

That looks like the Dashboard tab - not the Docker one

You can do it yourself by editing the first post in the thread and add "(SOLVED)" to the title.

I personally have no experience of software like ‘badblocks’, the only way I have tested my own disks is via preclear; extended SMART tests; or the manufacturer’s supplied test software. So far I have not had any drives that have failed early so I have no idea how significant a problem ‘infant mortality’ actually is in the real world and how the different testing methods fare against each other in triggering it.

Except that they cannot be ‘user shares’ in the normal Unraid sense and Unassigned Devices are completely ignored by the ‘mover’ application. You can store files that have similar purpose on an Unassigned Device but not in share with those names, and there is no automated copying of files to the array by the ‘mover’ process.

You might find this information of interest.

The main downside of Unassigned Devices drives is that they cannot be part of the Unraid User Share system. Depends on whether that matters to you.

Click on the first post in the thread; select the option to edit it; and then add ‘(SOLVED)’ to the title.

You cannot have any have any data drive that is larger than the smallest parity drive so your steps will not work! The procedure to achieve what you want is the Parity Swap one that is covered here in the online documentation that can be accessed via the 'Manual' link at the bottom of the Unraid GUI.

Just a caution - it will require you to be running a release more recent than 6.9.0 beta 35 to be able to use this option as it requires a feature that Limetech have only just added for this new capability to be available. It will not work on currently available releases.

I think you need to run the 6.9.0 beta release to have a driver for the NIC on your new motherboard.

There are definitely issues with drives on ata3 and ata4. They are not necessarily drives 3 and 4 so you might want to check that. If you post the system’s diagnostics zip file (obtained via Tools -> Diagnostics) we might be able to give more informed feedback.