JorgeB

Sorry, got my threads mixed up, the problem was almost certainly caused by the disk, it still has some pending sectors, but since the SMART test was successful it's fine for now, you can re-sync parity, pending sectores should also go to zero after a full disk write, but if you get more errors in the near future best to replace it.

It completely successfully so most like a controller issue.

Sorry, nothing jumps out, try running the server in safe mode for a couple of days.

A date/time when it crashed would help.

It it's just with Revit it probably won't be easy to help, were the diags downloaded when you were experiencing the non responsive Revit? If not please post new ones so we can at least see if Unraid is doing anything during that time.

Or keep a file with the same name on the array, it won't move existing files.

Thanks for reporting back, if you don't mind I'm going to tag this solved.

Some tips here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Should work mostly fine.

Are those devices unassigned?

I said it looks more like a controller issue, you can (and should) still run an extended SMART test on parity to confirm, but even if the disk is the problem for now I would still recommend replacing that controller since it will likely cause trouble sooner or later.

Yes, parity sync or correcting parity check is still needed after.

Sync errors are likely the result of the previous issues, run another check after this one finishes without rebooting and post new diags if there are more sync errors.

If possible try another flash drive, also make sure it's on a USB 2.0 port.

This is usually set in the board BIOS, reset CMOS, it should be enable by default

No update available, you need a new one.

It should be since the disk is still mounting, as long you have available space.

Very unlikely for check --repair to work for this, and it might makes things worse.

Possibly a controller issue, though problem appeared to start with a disk first, in any case recommend updating LSI firmware to latest since it's on a very old one, and check all connections. May 11 00:48:19 Tower kernel: mpt2sas_cm0: fault_state(0x4101)! May 11 00:48:19 Tower kernel: mpt2sas_cm0: sending diag reset !! May 11 00:48:20 Tower kernel: mpt2sas_cm0: diag reset: SUCCESS

Not that I know of.

Note that you'll need to change the xfs UUID to be able to mount both disks at the same time, you can do that for the disk outside the array with: xfs_admin -U generate /dev/sdX1

Transid error with btrfs is usually fatal, and it's usually caused by writes not being completely flushed to disk, there are some recovery options here, btrfs restore is likely the best one for this. There are constant ATA errors with disk3, and possibly the reason for the fs becoming corrupt: May 10 22:48:22 MitchFlix kernel: ata6.00: status: { DRDY } May 10 22:48:22 MitchFlix kernel: ata6.00: failed command: READ FPDMA QUEUED May 10 22:48:22 MitchFlix kernel: ata6.00: cmd 60/40:78:20:bf:1e/05:00:31:00:00/40 tag 15 ncq dma 688128 in May 10 22:48:22 MitchFlix kernel: res 40/00:a0:c8:d6:1e/00:00:31:00:00/40 Emask 0x50 (ATA bus error) May 10 22:48:22 MitchFlix kernel: ata6.00: status: { DRDY } May 10 22:48:22 MitchFlix kernel: ata6.00: failed command: READ FPDMA QUEUED May 10 22:48:22 MitchFlix kernel: ata6.00: cmd 60/a8:80:60:c4:1e/02:00:31:00:00/40 tag 16 ncq dma 348160 in May 10 22:48:22 MitchFlix kernel: res 40/00:a0:c8:d6:1e/00:00:31:00:00/40 Emask 0x50 (ATA bus error) May 10 22:48:22 MitchFlix kernel: ata6.00: status: { DRDY } May 10 22:48:22 MitchFlix kernel: ata6.00: failed command: READ FPDMA QUEUED May 10 22:48:22 MitchFlix kernel: ata6.00: cmd 60/40:88:08:c7:1e/05:00:31:00:00/40 tag 17 ncq dma 688128 in May 10 22:48:22 MitchFlix kernel: res 40/00:a0:c8:d6:1e/00:00:31:00:00/40 Emask 0x50 (ATA bus error) May 10 22:48:22 MitchFlix kernel: ata6.00: status: { DRDY } May 10 22:48:22 MitchFlix kernel: ata6.00: failed command: READ FPDMA QUEUED May 10 22:48:22 MitchFlix kernel: ata6.00: cmd 60/40:90:48:cc:1e/05:00:31:00:00/40 tag 18 ncq dma 688128 in May 10 22:48:22 MitchFlix kernel: res 40/00:a0:c8:d6:1e/00:00:31:00:00/40 Emask 0x50 (ATA bus error) Check/replace cables.

As a way to be able to compare the data on the rebuilt disk vs old disk, then if all OK you can rebuild again on the old disk (or do the new config).

There's no reason to think that any data is missing/damaged but It's up to you, though IMHO instead of doing that a better option would be to rebuild to a spare disk.

Not normal but likely the disk was used with zfs before, xfs partition is still mounting correctly, check contents look correct, don't forget to unmount before the new config.