itimpi

All motherboard/CPU combinations have limits on the max RAM speed they support and this can vary according to the number of RAM sticks plugged in. As far as I know this has always been the case for PCs. Normally one looks this up for your particular hardware and (assuming you can afford it) you buy RAM that is fast enough to handle the fastest clock speed the motherboard/CPU can handle to maximise performance. For some reason these limitations are often not clear in the documentation that comes with the motherboard although to be fair AMD have published it. It is often complicated by the fact that AMD CPUs can typically support being overclocked albeit at the risk of compromising stability.

It normally resides in the config folder on the flash and has a .key extension. Do you know which drives are parity drives? The key thing is not to assign any data drives to parity as this would destroy the contents. If you are not sure then this section of documentation gives a procedure you can use.

There is the “ParitySwap” procedure that is designed specifically to handle this case. However I have no idea if it is available in a release as old as 4.7 - maybe someone will have a long enough memory to answer that question. The answer might determine the best route forward.

It should be a folder on all releases so it sounds as if your config folder backup is corrupt

The motherboard/CPU combination can impose maximum RAM clock speed limitations that can be lower than the maximum speed the RAM itself is rated for

If the a folder exists for any share on the cache drive (even if it is empty) then the free space of the cache drive will be included in the free space value for the share shown in Windows.

You need to see if this keeps increasing at anything other than a nominal increase. . CRC errors are connection issues and more often than not are cabling related rather than the drive itself. CRC errors never get reset so you just need to check it is not increasing much.

Also you cannot add a parity drive and a data drive at the same time (not sure if you are trying to do this), - it has to be done in 2 steps.

I think it is quite possible that a running pre-clear can cause any other array operation that normally finishes with a ‘sync’ operation (that I expect format does) to hang until the pre-clear either finishes or is stopped. Could be wrong about that as it is just a theory

If you are running 6.9.2 then you could just set up another pool rather than use it as an unassigned device. Doing that way means the new pool can participate in User Share whereas a UD managed drive cannot.

Not the wrong logs - but the incomplete set of diagnostic files. The zip file you get via Tools->Diagnostics has much more than just logs in it. It may not be that drive - but with it writing so many error messages to the log it is easy to miss something else of significance.

No - only physical drives attached to the server at array start time are counted. There should be something in the logs indicating why you cannot mount.

You are getting continual I/O errors on a device SanDisk_SSD_PLUS_2036B2802141 so maybe that is the cause of your problems? I think it is probably sn Unassigned Device but I am not sure. Since yo did not provide the full diagnostics zip file (which contains more than the syslog) it was no possible to check ings like he SMART information. Would suggest you definite;y want to check cabling to that drive at the very least.

No - if you loose a drive then unRaid can rebuild onto a replacement drive exactly the same file system by working at the sector level. It works at the sector level, not the file level. What you cannot do via this process is change the file system on the drive.

any time you remove a drive you will need to rebuild parity as the contents of a parity drive is calculated using ALL the data drives, so removing one means a component of the parity calculation is missing. Having dual parity makes no difference as the same principle applies but using a different calculation for the second parity drive.

If that is the new drive then you either have a cabling issue or the disk itself is faulty. The results seem to point towards it being the disk. if possible I would suggest plugging it into a Windows/Mac and running the manufacturers diagnostic tools (Seatools I think) to see what it reports.

According to the syslog you seem to be getting continual errors on drive with model ST10000VN0008 and serial ZS50MLLR. In addition it does not provide valid SMART data. Is that the one you are trying to add?

UnRaid is not using COW - just a simple copy that it looks like is being aborted prematurely. I would expect the copy that appears to be ‘stuck’ on the cache to be fine.

You should provide your system’s diagnostics zip file (obtained via Tools->Diagnostics) which might allow us to give some informed feedback.

Sounds as if something else is going on. You should post your system’s diagnostics zip file (obtained via Tools->Diagnostics) so we can get a better idea of what is happening and provide sensible advice.

@Squid I agree with you description of what is happening. Sounds like a bug in mover and mover should have a way of being told to needs to forcibly close down and tidily remove the (incomplete) target file before exiting.

It sounds like a bug in the shutdown code then where the mover process is being forcibly aborted leaving behind an incomplete file on the array rather than shutting down tidily and making sure that any partially copied file on the array is removed. Because mover never overwrites existing files on the array this would give the symptom you describe of the file getting 'stuck' on the cache.

You need to make sure that it is being captured as a "short" press to initiate the Unraid shutdown sequence. If it is being treated as a "long" press then that is captured by the BIOS and does an immediate poweroff bypassing Unraid.

Have you tried a short press on the real power button to see if that works? You need to get the Pi out of the loop at this stage and make sure that is being captured, and if not then look into why. If that seems to be captured but the system does not shutdown tidily then it is probably worth raising it as a bug report.

Normally it is by issuing the 'shutdown' command from the GUI or the command line. If trying to do it via simulating pressing the power button then you must simulate a short press (just a few seconds) which should also initiate the shutdown sequence. What you must NOT do is simulate pressing the power button for a long time (e.g. 30 seconds) as that will force the BIOS to do an immediate cut of the power.