Running Unraid version 7.3.2

My cache pool (consisting of 2 SSD) stopped working and the status icon for one of my SSDs (device 2) was red and unresponsive to attempts to SMART check. So I assumed the drive was dead and I purchased a replacement. I swapped out the dead drive for a new one (of larger size) and when I turned on the server I assigned the new disc to the missing cache slot (device 2). I started the server (I did not select maintenance mode, though I now wish I had) and it is running a parity check, which is ongoing. But what surprised me is that the Array Operations still say there are "Unmountable disk present" and it lists BOTH cache SSDs, with the option to format both. Currently the status icon for device 1 (the disc with no issues that I am aware of) is green with normal/active operations.

I am unclear if this status is normal after a failed cache disc, or if I am dealing with multiple issues at once. I've attached my SMAR T report for device 1 (the "good" drive) that I obtained before disc replacement which looks like it is healthy (to me). When the parity check finishes, will I be able to resume mounting my new cache drive? I'm thinking not. I can see in the Unraid Docs that I should fix any unmountable discs before replacing. I believe my next step will be to run the steps here:
https://docs.unraid.net/unraid-os/troubleshooting/common-issues/data-recovery/#unmountable-disks

Since this is a cache disc and not a data disc, how do I identify the "disk number" for the xfs_repair command?

SAMSUNG_SSD_830_Series_S0WENYAC301776-20260811-1908.txt

Please post the entire diagnostics zip

1 hour ago, zero_koop said:

I believe my next step will be to run the steps here:
https://docs.unraid.net/unraid-os/troubleshooting/common-issues/data-recovery/#unmountable-disks

Since this is a cache disc and not a data disc, how do I identify the "disk number" for the xfs_repair command?

SAMSUNG_SSD_830_Series_S0WENYAC301776-20260811-1908.txt

Those instructions are for array disks (not for pools). Also since you say your ‘cache’ pool had two disks in it it could not have been in xfs format as that is only allowed on single device pools.

As was said provide your system’s diagnostics zip file to get informed feedback.

Ah, thank you for correcting me. I've attached my diagnostics.

tower-diagnostics-20260812-1527.zip

I'll add that I basically followed the steps outlined in the replace a disk in a pool guide. But that resulted in the unmountable situation. Since one of the original cache pool disks is healthy, do you think I should go through the steps of removing a disk from a pool before trying to add the new replacement disk?

Post output from btrfs fi show

4 hours ago, JorgeB said:

Post output from btrfs fi show

Output while array was running:

Label: none  uuid: 4aedd212-ad60-4abf-9d83-5efbf50ef4d1
        Total devices 1 FS bytes used 448.00KiB
        devid    1 size 20.00GiB used 536.00MiB path /dev/loop2
Couldn't read tree root

Label: none  uuid: defdcbbc-db9c-459a-a3d6-d3cac4d86547
        Total devices 2 FS bytes used 80.51GiB
        devid    1 size 119.24GiB used 111.23GiB path /dev/sdg1
        *** Some devices missing

When the array is stopped the output is only that second label block ("defdcbbc...).

Any idea what happened to the missing device?

1 hour ago, JorgeB said:

Any idea what happened to the missing device?

The ADATA drive that I replaced was unresponsive. I'm assuming it just died. Initially I replaced it and added it to the pool, but I removed it again to see if that changed anything to make the remaining mountable.

What I don't understand is why the tree root was not fully replicated on the remaining drive. That's why I put in a second cache drive, for redundancy.

Would need previous diags to see the actual pool status; possibly it wasn't actually running as a mirror. The problem is that other than the missing device, the superblock on the remaining pool device is damaged, try this

btrfs-select-super -s 1 /dev/sdg1

Then restart the array and post new diags.

7 hours ago, JorgeB said:

Would need previous diags to see the actual pool status; possibly it wasn't actually running as a mirror. The problem is that other than the missing device, the superblock on the remaining pool device is damaged, try this

btrfs-select-super -s 1 /dev/sdg1

Then restart the array and post new diags.

I just get:

Couldn't read tree root

ERROR: open ctree failed

Should I try this:

btrfs rescue zero-log /dev/sdg1

You can, but I don't expect that to help in this case. You can also try the recovery options here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

3 hours ago, JorgeB said:

You can, but I don't expect that to help in this case. You can also try the recovery options here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

Thanks for your help. Nothing was successful so I guess it looks like it was a total loss. I really do not understand what happened. My system was running great just a few days ago. I thought I had redundancy of drives in my cache system for this exact kind of situation (single disk fail). I guess this was a double disk fail. I am just disappointed. I will swap out both cache drives for new drives and build from there. My data is safe, which is great, but my appdata is gone along with all of the configurations of my dockers. I turned off the appdata auto backups years ago (at least I think I did) because I didn't think it was needed with redundant drives.

One last thing you may try is to disconnect any devices that were ever used or tried to be used with that pool and retry the recovery options. It doesn't look like the issue here; but in some rare cases, another damaged device from the pool can interfere.