8 minutes ago, trurl said:

Possibly something you did changed parity or some other disk so the emulation is producing different results than before.

That's possible, I didn't mount any of the other disks, but I was having a weird issue with them dropping out. Which I think caused this in the first place.

I'll post the end of it when it's done. Right now it's a lot of "imap claims in-use inode (number) is free, would correct imap" and a few "badness in key lookup (length)."

I'll let it keep running, but I'm guessing I may have to go to the physical disk and see if there's anything readable to copy from it.

1 minute ago, TVsIan said:

may have to go to the physical disk and see if there's anything readable to copy from it

It's possible the physical disk is different from the emulated disk, since emulation is suspect due to other activities.

It's also possible the physical disk is also unmountable, but check filesystem on the physical disk as an Unassigned Device might produce better results than repairing the emulated disk.

That is why we always recommend repairing the unmountable emulated disk before rebuilding the unmountable emulated contents onto the same disk.

It's still running, but while I'm waiting I mounted the disk as an unassigned device and took a look, and at first glance it at least looks like my data is there.

44 minutes ago, TVsIan said:

at first glance it at least looks like my data is there.

If it mounted then probably what is there is OK and it's probably most of what should be there. Anything written to the (emulated) disk after it became disabled would be missing.

Finishing the repair won't be as good as what you have on the physical disk. Some small chance that anything written after the disk was disabled could be recovered, but more likely it would just end up as lost+found along with much of everything else, assuming repair can even be completed.

Do you have any idea what might have been written after the disk became disabled?

Not much, if anything. Maybe a couple of logs for my Docker containers. I suspect I would be absolutely fine using the data on the disk and ignoring the emulated disk.

What would be the next step on that? I assume I can format the emulated disk and manually copy before adding the disk back to the array, but it there a better way?

The filesystem on the emulated disk appears to be a loss anyway:
would have junked entry "ply" in directory inode 1496476592

would have corrected i8 count in directory 1496476592 from 2 to 1

would rebuild corrupt refcount btrees.

No modify flag set, skipping phase 5

Inode allocation btrees are too corrupted, skipping phases 6 and 7

Maximum metadata LSN (2135175357:1264576416) is ahead of log (0:0).

Would format log to cycle 2135175360.

No modify flag set, skipping filesystem flush and exiting.

XFS_REPAIR Summary Tue Mar 17 16:46:16 2026

Phase Start End Duration

Phase 1: 03/17 15:08:55 03/17 15:09:01 6 seconds

Phase 2: 03/17 15:09:01 03/17 15:09:04 3 seconds

Phase 3: 03/17 15:09:04 03/17 16:46:02 1 hour, 36 minutes, 58 seconds

Phase 4: 03/17 16:46:02 03/17 16:46:16 14 seconds

Phase 5: Skipped

Phase 6: Skipped

Phase 7: Skipped

Total run time: 1 hour, 37 minutes, 21 seconds

You can New Config the physical disk back into the array and rebuild parity.

Thank you! I had to shut the server down due to the issue that I think caused this in the first place, but the array appeared intact.

Just to help anyone in the future - the Dell HBA330 and other cards based on the LSI SAS3008 have an issue with firmware versions older than 16.12. There are problems with SATA drives, and in Unraid this appears as a series of errors followed by the drive going offline. It may or may not appear in unassigned devices afterwards if it comes back online. It also puts the array in a weird state where it seems like it's trying to keep running despite 2+ drives being unavailable.

The problem didn't show up when I was leaving Mint up for an extended amount of time, but the drives weren't mounted and it seems like writes trigger the issue. I'm fairly sure this isn't restricted to Unraid.

I attempted to flash it with the generic firmware since Dell stopped updating it after 16.11, but Dell has a lock to prevent non-Dell firmware from being crossflashed onto it. The jumper to bypass that doesn't seem to exist on the HBA330 Mini and I didn't see any evidence the PCIe versions have it either.

So I'm shut down until I get my hands on a replacement card, likely an H730/H730P that I'll run in HBA mode. My research before getting the hardware all said for Unraid or something like TrueNAS, use the HBA330 rather than a RAID card. I suspect the people who had success with that were running SAS drives. For the H730, I've seen mixed reports. Some "It may work now, but you'll have unspecified problems in the future," some "It works fine but SMART isn't available," and even "Everything works including SMART."

Edited March 18Mar 18 by TVsIan