itimpi

There should be a difference if you have NO mechanical drives in the array. However the moment you introduce mechanical drives into the mix then much of the speed benefits of SSD will disappear as any write to the array which involves a mechanical drive as one of the participants in a write operation it will be slowed to the performance op that mechanical drive.

Yes - by default the 'appdata' share is set to reside on the cache so you effectively removed its contents from the system. As you still seem to have the old cache drive contents intact you can copy them back to the new cache drive.

I use a Palit 1050ti kalmx which works fine for me. One of my requirements was that it should be fanless (and thus silent) which precluded any newer cards I could find. I think you can pick that up on eBay for around £50-£60 at the moment.

You cannot (currently at least) schedule items via the User Scripts plugin to run at boot (although it has been hinted some additional scheduling options might be added). If you want it run as part of the boot process then add the commands to the config/go file on the usb drive.

The Nvidia plugin has the current Unraid release (6.8.3) available so that should not be a problem. Note however that the Nvidia plugin is irrelevant if using a VM as the VM supplies the Nvidia drivers - it only matters when using Docker containers where you want hardware transcoding support.

Both plugins and docker containers should be installed via Community Apps nowadays. The unassigned Devices plugin is definitely available there - I have just checked on my system.

The CRC errors are connection issues and typically relate to power/SATA cabling. The never reset so you just want them to stop increasing (or increasing very slowly).

The parity.check.tuning warning is harmless (and will be fixed when I release the multi-language compatible version). The hypervisor message probably relates to the VM backup olugin if you have that installed.

Those are different views of the same file ! the cache location refers to the physical drice(s) in the cache. The user location is the User Share view which spans all array drives plus the cache.

Attach your system diagnostics to your next port (obtained via Tools -> Diagnostics to your next post so that we can see the configuration information for your server.

You could be getting the stutter because the system is temporarily locking up in the kernel as all the drives are being spun up to populate the Main or Dashboard information. If you have manually spun up all the drives before trying to access those tabs do you still get the stutter?

You get an initial delay before the console prompt as UnRAID is loaded into RAM and hardware detection is carried out. The next delay will be after the core Linux underlying Unraid is ready (which is when the console prompt appears) as UnRaid carries out the remainder of the boot process and Is mounting the array and starting up the underlying system services. If you do not have the array set to autostart then you get access to the GUI earlier but then have to manually start the array and get a delay at that point.

No. By default the logs are only kept in RAM and thus the diagnostics you posted do not cover the failure period. The link was for a method for getting logs that DO survive a reboot.

According to the SMART reports both disk3 and disk6 are faulty and need replacing.

Unraid runs from RAM which is why it did not survive a reboot. If you want any file to survive a reboot then you need to store a copy on the flash drive and copy it into its runtime position using either entries in the config/go file or using the User Scripts plugin.

A disk gets disabled when a write to it fails for some reason. How to handle a disabled disk is described here in the online documentation.

Both desk3 an disk6 are getting continual read errors so not much point in trying to continue the parity sync. Both drives also show pending sectors in their SMART reports which indicate some sectors that cannot currently be read reliably. I would suggest that the following steps are a good idea: Check the power/SATA cabling to the drives as this is the commonest cause of disk problems Run the extended SMART test on both drives to check them out. After doing that you might want to post new diagnostics so we can see what the SMART tests reported.

You can encrypt the disk by stopping the array; clicking on the drive on the Main tab; change the file system to the encrypted type you want and then restart the array to get the option to format as an encrypted disk. Doing so will erase the current contents so make sure you have first copied elsewhere anything on the drive you want to keep.

Yes. all your settings and licence key are stored in the config folder so if these files are all intact and not corrupted your system will come up exactly as it used to. This set of steps will help if for any reason Unraid is having problems loading any of the bz* type files on the flash when booting.

The Reconstruct Write (Turbo Write) should have no effect on Parity build times. It should only (under the right circumstances) speed up writing to array data disks. I have no idea why it seems to have helped with parity build.

Do you have your monthly parity check set to be ‘correcting’ or not? Note that If you provide the system diagnostics zip file we could look in there to find out. Non-correcting is the recommended setting so that you do not corrupt parity if a drive starts acting up, but if set that way no errors will get fixed until you run a correcting check so the number would not go back to zero. Have you had any ‘unclean’ shutdowns for any reason. Any time you get one of those it’s likely that a few parity errors would happen after rebooting. you DO want to get back to having zero errors as that is the only way you can expect a rebuilt disk (if you have a drive fail) to have no file system corruption. Assuming your monthly checks were non-correcting and you think all your drives are healthy then I would suggest your best course of action is: run a correcting parity check - this will report the number of errors it has corrected then run a non-correcting parity check to make sure the number of errors is now zero it might make sense before doing this to post your system’s diagnostics zip file (obtained via Tools->Diagnostics) so we can check if anything appears to be amiss that you have not mentioned.

Any time you get an ‘unmountable’ disk showing that previously mounted OK (including one being emulated) then the way to recover from this is to run a file system check/repair. A rebuild will never fix this state as it will simply rebuild back to the same ‘unmountable’ state.

Anything that is on a non-failing drive will be safe.

When you did the New Config did you use the option to keep current assignments? Just asking as the parity2 calculation uses disk slot number as one of its inputs so moving any drive to a different slot would invalidate parity2 and could thus cause this sort of effect. Parity1 is not affected by which slot drives are in so is not affected if you re-order drives.

You have to remove the 'n' option or it will only be a check and not a repair.