JorgeB

Like mentioned avoid unclean shutdowns, they can cause other issues.

Yes, but there are more risks running btrfs raid5/6 pools, there are still some known issues and bugs, and if there is a problem you can lose the whole pool, you can still use them, I do and have multiple raid5 pools, just be aware of the possible issues and keep good backups.

Strange that it doesn't auto start after an unclean shutdown, but first thing would be to avoid those.

No. Read the release notes.

Stop the array and do a clean reboot, then post new diags after array start. P.S. there's an unassigned 3TB Seagate spamming the log, if you're not using it disconnect it.

What HBA? or post the diagnostics: Tools -> Diagnostics

Changed Status to Closed Changed Priority to Other

Newer kernel can detect previously undetected corruption, downgrade back to v6.8 and see if it still mounts, if yes, backup and re-format.

Try this: https://forums.unraid.net/bug-reports/prereleases/solved-690-beta25-through-690-rc1-syslog-server-broken-error-in-logs-r1003/?do=findComment&comment=12179

Most drives are pretty hot, you should improve cooling.

Try upgrading to 6.9 stable

Type "diagnostics" in the console then attach here.

It's not common with good hardware, still wouldn't worry about one time, but if it keeps happening there's likely some hardware issue.

You can also see here for some numbers, with single and dual link.

Mar 5 15:20:05 Tower kernel: pm80xx 0000:09:00.0: pm80xx: driver version 0.1.38 Mar 5 15:20:05 Tower kernel: pm80xx 0000:09:00.0: Refused to change power state, currently in D3 Mar 5 15:20:05 Tower kernel: pm80xx pm8001_pci_probe 1047:pm8001_request_irq failed [ret: -28] Mar 5 15:20:05 Tower kernel: pm80xx: probe of 0000:09:00.0 failed with error -28 Controller is failing to initialize, you can try a different slot if available, but there have been other issues with this controller, e.g., also known to stop working after updating to v6.9, would recommend using an LSI instead, you'll need a new cable though.

Please post the diagnostics: Tools -> Diagnostics

You can do that with a new config, but parity2 will need to be re-synced.

Nope, just that there were a handful of cases reported, IIRC always with the ST8000VN004 model, though other capacities might have the same problem, and always fixed by downgrading to v6.8 or moving those disks to a different controller.

Likely yes, there have been other users with similar issues with that plugin and v6.9.

For now you can wait to see if anyone else replies here. P.S. I edited the topic so the issue is more clear.

If it fails grab diags in v6.9 before rebooting.

Spin down is no longer handled by mdcmd but by emhttpd, not sure if there's a new command we can now use for spin up, I'm also interested in that.

Unmontable/unassigned cache won't prevent array start, but difficult to say more without diags.

Rebuilding won't fix the filesystem corruption. No, but you cancel the rebuild, run the file system check and then start over.

Oops, wiki changed, basically, stop array, unassign that disk, start array, stop array, re-assign the disk, start array to begin rebuilding.