JorgeB

Since it's a Revit known issue going to downgrade this for now, and I don't think LT can do anything about it, but lets see.

Did just that and can confirm I can reproduce your issue, looks to me like Revit is doing sync writes, and this appears to confirm it: https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Revit-slow-saving-to-SMB-share.html

[14:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg8 state=running queue_depth=1 scsi_level=6 type=3 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/14:0:0:0 [/sys/devices/pci0000:00/0000:00:1c.6/0000:0c:00.0/ata14/host14/target14:0:0/14:0:0:0] [22:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg9 state=running queue_depth=1 scsi_level=6 type=3 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/22:0:0:0 [/sys/devices/pci0000:00/0000:00:1c.7/0000:0d:00.0/ata22/host22/target22:0:0/22:0:0:0] In that case some of those ports are from a Marvell controller, since the SSD is currently using one.

You should try safe mode.

ATA22 (and ATA14) are Marvell related virtual devices, not actual devices, you can ignore the errors, but we don't recommend using Marvell controllers with Unraid.

Most likely, but don't remember seeing that error before, can you try again after updating to v6.8?

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