Hello all,

this is my first post here. Some days ago I updated Unraid from 6.12.10 to 6.12.11. After the reboot my "Cachepool" disk was gone and also not listed anywhere but in "Historical Unassigned Devices".

As another reboot did not help I did:
- remove the disk from historical unassigned devices (no idea why it was there anyhow)

- "New Config" (wrong idea?)

 

Anyhow I ended up having the disk removed from the System and noticed SATA cable is damaged (broken insulation at two points) so I bought a new one, but nothing changed. Connected monitor for booting to UEFI: SATA disk also not visible. External adapter on Windows & Linux machine: nothing.

 

First question: Did the SSD disk completely fail coincidentally at the same time the update & reboot happened?

 

Finally started the array without the "Cachepool" disk and from first sight nothing seems obviously wrong. But I'm not 100% sure how I configured it (what to save on this disk except cache?)

 

Second question: How can I find out if there was at all data on the cache disk at the time of failure?

 

Thanks for your help  

 

Background info about system:

Intel NUC7i3BNB

M2 SSD as "Ssd_pool"

SATA SSD as "Cachepool" (this one failed)

External 4TB HDD as Data Disk

External 4TB HDD passthrough to VM

several VM and docker container

 

Screenshot (Main) with missing disk:

Screenshot (Main) now:

Screenshot (Shares) now:

riunraid-diagnostics-20240822-1816.zip

7 minutes ago, BlueGray said:

Second question: How can I find out if there was at all data on the cache disk at the time of failure?

If you can't read it you can't find out what was on it.

4 minutes ago, trurl said:

If you can't read it you can't find out what was on it.

Based on my last screenshot, can I safely assume that if there was any data on it, it was only "not yet moved cache data"?

Any way to find out when mover completed the last time? 

Further question: Can I simply connect and assign a new ssd to the same slot or will Unraid get confused by this?

8 hours ago, BlueGray said:

only "not yet moved cache data"?

The way your shares are configured, it won't currently write other shares, such as appdata, to cachepool. No way to know if there was already data from those other shares on cachepool.

 

For example, even though your system share is configured to be kept on ssdpool, it actually has some of its files on the array. Probably created there when you enabled Docker/VM Manager before your pools were setup.

 

Nothing can move open files, so you would have to disable Docker and VM Manager before that share could be moved off the array.

3 hours ago, BlueGray said:

assign a new ssd to the same slot

You can

@trurl Thank you for the explanation!
So as long as all Docker/VM run fine, there's nothing else I can do probably, right?

 

To avoid data loss in future, might it be better to add the SATA SSD to the "Ssd_pool" where also the M2 SSD is assigned and have the pool used for Docker/VM and Cache? The SATA SSD was quite new (several month) and I already had a failed M2 some month earlier (before Unraid).

 

It seems the SSDs often fail completely and without warning, while I basically never had a HDD really failing completely in the last 20 years  (just replacements because of bad SMART values)

13 hours ago, trurl said:

even though your system share is configured to be kept on ssdpool, it actually has some of its files on the array. Probably created there when you enabled Docker/VM Manager before your pools were setup.

 

Nothing can move open files, so you would have to disable Docker and VM Manager before that share could be moved off the array.

When system share is on the array, Docker/VM performance will be affected, and array disks can't spin down since these files are always open.

10 minutes ago, trurl said:

When system share is on the array, Docker/VM performance will be affected, and array disks can't spin down since these files are always open.

I did not think of putting system share on the array but in the same pool as the cache. So I would have one pool for system + cache instead of separate ones. That would give me the option to use the spare slot as a mirrored disk for cache, right?

When we say array, we mean specifically those disks that are assigned as Array Devices, including parity. Cache is not part of the array.

 

10 hours ago, trurl said:

When system share is on the array, Docker/VM performance will be affected, and array disks can't spin down since these files are always open.

My point here is that some of your system share is on the array. It is configured to be moved to ssdpool, which is fine. But it can't be moved because nothing can move open files, and these are open when Docker and/or VM Manager is enabled in Settings.

11 hours ago, trurl said:

My point here is that some of your system share is on the array. It is configured to be moved to ssdpool, which is fine. But it can't be moved because nothing can move open files, and these are open when Docker and/or VM Manager is enabled in Settings.

Okay, got that point now and did the following:

• disable Docker + VM Manager in Settings
• manually triggered the mover
• checked computed size of system share: shows only "Ssd_pool" now
• reenabled Docker + VM Manager
• removed the secondary storage (Array) from system share settings

During the process I noticed that only libvirt.img seemed to be on the Array still while docker.img was on Ssd_pool already. Is it correct only these two files are in system share?

 

But I think my other question remains: What of the following would be the better solution?

1. Replacing the dead ssd with a new one in the same slot and config as before: Meaning 1 pool for Docker+VM and 1 separate pool for Cache (each pool with one physically separate SSD)
2. Adding the replacement SSD as second disk to the "Ssd_pool" and using this pool for Docker + VM + Cache/Primary storage: only 1 pool but with two disks in RAID 1

 

Thank you very much for your help so far

I would do 1. same as before. But that would give no redundancy anywhere including the array.

 

You could get pool redundancy with 2.

 

NUC is not a good platform for parity array anyway.

 

Make sure you have good backups.