JorgeB

I said to use btrfs restore.

Data from delete snapshots (not reference anywhere else) is immediately deleted, though it can take a few seconds or even minutes for very large filesystems to cleanup, note that depending on the btrfs pool config used and Unraid version it can show incorrect used space, free space or both for some btrfs pools, depending on profile and number of devices.

We usually recommend once a month. Your parity devices are still invalid, Unraid is doing a parity sync, not a check, only after parity is valid you can do a check, if you cancel/shutdown the array before the sync is done it will start over from the beginning next time array is started.

Wait for the parity sync to finish, trying to use the array while it's not done will result in very bad performance.

Same thing as any other JMB585 controller, depends if you prefer to use a PCIe slot or an M.2 slot.

I don't know what this is.

Does the same happen after booting in safe mode?

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ? S Sep12 0:00 [kthreadd] root 76 95.6 0.0 0 0 ? R Sep12 950:33 \_ [kworker/1:1+pm] root 31 95.3 0.0 0 0 ? R Sep12 947:35 \_ [kworker/4:0+usb_hub_wq] Yeah, not sure what these are but it's strange, especially the USB HUB part, not sure what the other one is, does it go away if you reboot?

Please post the diagnostics: Tools -> Diagnostics, might show what the problem is.

Because it was only found and reported on the latest beta, it should be fixed on the next one.

Yes, you can use for example midnight commander (mc on the console)

Turbo write helps with speed, parity will still be overused compared to data devices, if for example you have 10 data devices, over time parity will have 10 times the number of writes of any data device, so you want a device with better endurance and since it can't be trimmed and will be much more used faster performance will also help.

Correct.

Memtest won't find any errors unless ECC can be disabled in the BIOS, check the event log in the board BIOS/IPMI, there might be some more info, e.g.:

Please use the existing docker support thread, you can find it by clicking on it:

Yeah, it's a known bug, for now it needs to be done manually.

It's fine, sync finished successfully: Sep 12 10:10:05 unraid kernel: md: sync done. time=88414sec Sep 12 10:10:05 unraid kernel: md: recovery thread: exit status: 0 Strange the GUI was stuck, you do have something spamming your logs, no idea what these are about: Sep 10 20:47:40 unraid kernel: traps: node[14845] trap invalid opcode ip:560d6ce0270f sp:7ffc308bd0e8 error:0 in node[560d6cdfe000+77b000] Sep 10 20:47:41 unraid kernel: traps: node[15235] trap invalid opcode ip:5564cbf2c70f sp:7ffccd709a38 error:0 in node[5564cbf28000+77b000] Sep 10 20:47:42 unraid kernel: traps: node[15587] trap invalid opcode ip:5646aceda70f sp:7ffe15854878 error:0 in node[5646aced6000+77b000] Sep 10 20:47:44 unraid kernel: traps: node[16105] trap invalid opcode ip:55f17924770f sp:7fff2b8b0ea8 error:0 in node[55f179243000+77b000]

It's not the superblock, first error lines are the important ones, it's extent tree corruption, loos like part of it was wiped/trimmed, if it's just the extent tree btrfs restore should be able to recover most of your data.

Maybe this one?

Those ATA errors suggest the SSD also isn't very happy there, so probably a good idea to replace that controller ASAP, since the SSD shouldn't normally be as stressed as an array device during a rebuild it might be OK to use it there for some time.

It could be the controller, or some controller incompatibly with that drive if this is a new device, though Asmedia controllers usually work fine. You can try for example swap it with the SSD.

Still looks like a connection problem, if check/replace cables again, make sure also power cable.

No, that's not what you want, see here: https://wiki.unraid.net/Troubleshooting#Re-enable_the_drive

Because the diags are after rebooting we can't see what happened, but disk looks mostly healthy, so you can rebuild on top (disk appears to be empty though), still recommend replacing/swapping cables just to rule them out in case it happens again to the same disk.

Since the disk is being emulated it's not up or down, all the other disks plus parity are being used instead, you should post the diagnostics to see what happened, ideally after the disk got disabled and before rebooting.