JorgeB

That's weird since your disks were already using 512B sectors, in the link above did you try the format option posted first or went directly to the last option? That option is only for some SED disks.

Likely USB related, please post new diags after array start.

Nope.

Instead of shutdown/reboot press stop with all the VMs/dockers running and time how long it takes for the array to stop, or like mentioned posting the saved diags might also show what the problem was.

This, there won't be any assigned devices, so array won't start.

No, though it could have been done at the same time: https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

It's fairly safe to do, just remember that like mentioned in the release notes you'll need to reassign your cache.

Not really, if btrfs restore doesn't work for that not much else you can do, AFAIK.

Yep:

IIRC it's a known issue. Shutdown from the GUI can be unclean if one of the timeouts is reached, first one for VMs then the general timeout, when there's one the diags will be saved in the flash drive, logs folder, those can show what the problem is.

Dec 3 10:22:20 Tower emhttpd: unclean shutdown detected

Did you upgrade recently? Or started using i915 module for transcoding? If yes it could related to this:

Likely nothing, it might fail the next time, there were various errors before it was detected, assuming the disk is OK it could be a controller/cable problem. It's in the server, see here for a list of recommended ones: In the syslog, look for these and similar: Dec 3 05:33:13 UNICORN kernel: ata11: SATA link down (SStatus 0 SControl 330) Dec 3 05:33:40 UNICORN kernel: ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 330) Dec 3 05:33:45 UNICORN kernel: ata11.00: qc timeout (cmd 0xec) Dec 3 05:33:45 UNICORN kernel: ata11.00: failed to IDENTIFY (I/O error, err_mask=0x4) Dec 3 05:33:46 UNICORN kernel: ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 330) Dec 3 05:33:56 UNICORN kernel: ata11.00: qc timeout (cmd 0xec) Dec 3 05:33:56 UNICORN kernel: ata11.00: failed to IDENTIFY (I/O error, err_mask=0x4) Dec 3 05:33:56 UNICORN kernel: ata11: limiting SATA link speed to 3.0 Gbps Dec 3 05:33:56 UNICORN kernel: ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 320) Dec 3 05:34:16 UNICORN kernel: ata11.00: failed to IDENTIFY (I/O error, err_mask=0x100) Dec 3 05:34:17 UNICORN kernel: ata11: SATA link down (SStatus 0 SControl 320)

It's normal for parity not to have a mount option, since there's no valid filesystem, as for old disk1 and assuming the filesystem was the default XFS you can try running xfs_repair to see if it finds a backup superblock: xfs_repair -v /dev/sdb1

Is it this disk? Dec 3 05:34:53 UNICORN kernel: ata11.00: ATA-10: ST8000DM004-2U9188, ZR11ZNC1, 0001, max UDMA/133 If yes looks like the controller had a difficult time detecting, but appears to be detected correctly now, though Marvell controllers are not recommended.

Please post the diagnostics.

Check the System/IPMI Event Viewer, there should be more info there.

Drive isn't generating any read errors so far, and if it does parity2 will kick in, when the rebuild is done you can replace it.

As you prefer, results will be the same, but it's easier if you let it finish so you can just use that disk alone, and mount the array without it if needed.

There are ATA errors in multiple devices, could be a controller issue, use all the onboard SATA ports and then try again ideally with a different controller for the remaining two devices.

Without the diags it's more difficult to guess, but with dual parity I would likely continue with the rebuild.

It would have been much better to see if the emulated disk was fixable before starting to rebuild on top of the old disk, now you don't have the option to use it, and it would probably be fine, current filesystem corruption is fatal, you might be able to recover the data with btrfs restore, 2nd option here, after that you'll need to format the disk.

I know it happens, can't tell you exactly why as it's beyond my knowledge, likely because an expander is kind of like a switch. It will downgrade the performance of all connected devices, there are a couple of examples of that on the link I posted above.

Yes, it's a good option, it's listed above, also on the recommended controllers list.

Most likely, since the Microserver uses molex to SATA, so no 3.3v.