JorgeB

Run it again without -n or nothing will be done.

Enable system notifications so you're notified immediately when there's a problem. Problem itself looks more like a power/connection issue, replace/swap cables to rule that out and as long as the emulated disk is mounting you can rebuild on top.

Problem is caused by only having one array disk with btrfs, this makes parity appear to have a valid btrfs filesystem and generates an error during device scan: Mar 22 10:59:47 RizzoUnraid emhttpd: /mnt/cache_ssd ERROR: cannot scan /dev/sdl1: Input/output error Though strange that it doesn't happen with rc2, in any case best way forward to avoid this now and in the future is to either have more btrfs arrays disks on convert disk10 to xfs like the rest.

Could be, difficult to say, locking up with Ryzen is usually more related to the other issue I mentioned.

Check filesystem on disk5.

Mar 21 21:28:25 NAS4 kernel: BTRFS error (device sdi1): block=892079783936 write time tree block corruption detected Write time corruption detected by btrfs is 9 out of 10 times due to bad RAM. Ryzen with overclocked RAM like you have is known to corrupt data, see here, also make sure power supply idle control is correctly set.

It won't work the same.

Click on the link and you'll see the instructions.

Disk dropped offline, could be a connection/power problem, could also be a bad controller, replace/swap cables on that disks and if problems persist it's likely the controller.

You can generate a new one in the UD settings.

Sorry, can't really help with that, if you can't fix it best to start a new thread with an appropriate title.

Mar 22 00:06:15 Tower kernel: ata5: SATA link down (SStatus 4 SControl 300) Check/replace cables, both power and SATA.

Do you mean you can't connect to them using the GUI?

This, usually it's not a problem.

Yes, but difficult to say what, at least by me, see if it happens again, might have been a one time thing.

You can preserve all, then just un-assign disks 6 and 7, less work and also less chance of making a mistake. You can assign them as parity immediatly, but you can also start the array without them first if you want, either way all data on the remaining data disks will still be there.

You're virtualizing Unraid, while it should work it's another layer that can add issues, if you can I would first test running baremetal.

It doesn't happen without a reason, but would need the diags to see it, and if you want to post that please start your own thread.

Mar 21 17:21:37 Tower kernel: BTRFS warning (device sdn1): chunk 5466226688 missing 1 devices, max tolerance is 0 for writable mount Unraid is only detecting two pool members, the other one is being detected as new, and pool is mount because it wasn't redundant (or at least part of it). Mar 21 17:16:54 Tower kernel: BTRFS: device fsid 80736f28-b651-4f12-a638-45f718b8a9df devid 3 transid 856585 /dev/sdk1 scanned by udevd (1804) Mar 21 17:16:54 Tower kernel: BTRFS: device fsid f49492cf-a1df-488c-a31a-19d03ad6f2b0 devid 1 transid 38 /dev/sdu1 scanned by udevd (1866) Mar 21 17:16:54 Tower kernel: BTRFS: device fsid 80736f28-b651-4f12-a638-45f718b8a9df devid 2 transid 856585 /dev/sdn1 scanned by udevd (1822) And the above confirms that sdu is not part of the same pool, fsid is not the same, something happened to this device and it was re-formatted as a different (and newer) filesystem.

You have to do it without -n, or nothing will be done.

Check filesystem on disk5.

There were constant ATA errors for both disks.

Replace the SATA cable for cache1 and post new diags after array start.

You can only add a second parity once you remove the failing disks.