trurl

I notice you have 2 different sized SSDs in your list. How do you plan to use them?

If by native, you mean your option 3 that isn't an available option anymore and hasn't been for a very long time.

A single unrecoverable write error is all that is required to disable a disk, since that disk is out-of-sync with parity at that point.

https://wiki.unraid.net/UnRAID_6/Getting_Started#Manual_Method_.28Legacy.29

No obvious flash problems in that. On flash, the file config/super.dat is where your disk assignments are stored. If for some reason you don't get a good copy of that restored then it won't know your disk assignments.

Looks like your cache disks have dropped. Check connections and post new diagnostics.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-543490

You need to repair filesystem on disk2 (as expected). Capture the output so you can post it. Syslog is only since last reboot so no clue what might have happened. Setup Syslog Server so you can have syslog saved somewhere you can get it after reboot: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

Start the array and post new diagnostics.

Haven't looked at diagnostics yet, but rebuilding a formatted disk will result in a formatted disk.

And of course, everyone would ignore it. Or complain about it.

Still not seeing anything in syslog about mounting that remote. Whether or not it is automount isn't really that relevant to getting it to work. That is just so it will automount when the array is started. You need to get it to mount before automount can do anything. You just need to push the Mount button.

You want your VMs on cache. One of the reasons you don't want SSDs in the array is because their write speed will be impacted by parity updates just like with any disk in the array, but in the case of SSDs you have basically wasted the SSD speed.

That should have worked, and since it didn't it makes me wonder if you don't still have flash problems. Are you booting from a USB2 port? Recommended. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

On another note Apr 8 15:10:01 Tower root: Fix Common Problems: Warning: disk2 (OCZ-VERTEX3_OCZ-2AX8ITI487T12VZD) is an SSD. You have an SSD in the parity array. Not recommended for several reasons. But since you have no parity some of those reasons don't currently apply. Still, it can't be trimmed. Why don't you assign it as cache? That is the configuration you will want going forward.

As noted, if you had started the array, it would have said the disk was unmountable. That would have told you something was wrong. But of course, you already knew something was wrong. How about this scenario instead. You put the disk into another Linux computer, and you actually write something to it. In that case, it will still mount, but it is out of sync with parity, and if you didn't know you had to rebuild parity, then you could have just continued on, and if you never corrected parity, then you wouldn't be able to rebuild another disk. Short of a parity check, how can Unraid know you haven't done anything to any of your array disks when it was shutdown? And even then, it won't know why parity is out-of-sync. How could it?

One of the worst SMART reports I have ever seen. Replace ASAP.

I don't think I've seen any of those complaints. Unraid parity is realtime. Rebuilding parity isn't something that is done often. In fact, you may not ever need to do it after the initial parity build.

That is a good start. It would be enough for me and the way I use cache.

Cache is intended for temporary storage of files that will be moved to the parity array. It is also used for files related to dockers and VMs so they will perform better. Best to not even try to cache the initial data load since cache won't have the capacity. After that, you can decide how much you want to cache and how often you want it moved. Mover is intended for idle time. I recommend not caching anything except your dockers and VMs until you get a better idea how you will use the system. Trying to cache everything all the time is usually a mistake.

Note that if you do instead decide to remove the drive without replacing / rebuilding it, then having it empty will not be enough to allow parity to remain valid. An empty drive is not a clear drive.

From your other thread, which I just replied to, it seemed like you wanted to replace the disk. If so there was no need to move anything off it since replacement would have just done the normal rebuild and all the data would be on the new disk.

Are you using the same power and SATA cables each time?