JorgeB

Something weird there, pools can't be xfs: With array stopped click on cache and set filesystem to brtrfs, if already that set to another then back to btrfs, is still issues after that please post diags.

Yes, it dropped offline again, this will cause havoc with anything using it, like dockers.

There are some recent UNC @ LBA errors on disk2, about 3 days ago, I would recommend running a scrub on at least another array disk, if errors are limited to disk2 then it was likely a disk problem, if they appear on other disks it's another hardware issue, most likely bad RAM.

Initial problem was caused by the cache device dropping offline, this can cause filesystem issues with both the cache file system and docker image, but everything looks normal so far on the last diags.

Try to get the complete diags, or at least the syslog.

Correct.

That's normal, after a few seconds hard shutdown is done.

I would assume it's enable by default on newer kernels. From my understating it allows using e.g. cp --reflink-always with xfs, also de-duplication support, but I don't keep up with xfs development.

It was a hardware problem, see if a reboot brings it back online, I only checked the first diags.

NVMe device dropped offline: Nov 21 15:03:30 Tower kernel: nvme nvme0: I/O 399 QID 4 timeout, aborting Nov 21 15:03:30 Tower kernel: nvme nvme0: Abort status: 0x0 Nov 21 15:03:40 Tower kernel: nvme nvme0: I/O 821 QID 2 timeout, aborting Nov 21 15:03:40 Tower kernel: nvme nvme0: Abort status: 0x0 Nov 21 15:03:47 Tower kernel: nvme nvme0: I/O 822 QID 2 timeout, aborting Nov 21 15:03:47 Tower kernel: nvme nvme0: Abort status: 0x0 Nov 21 15:04:00 Tower kernel: nvme nvme0: I/O 399 QID 4 timeout, reset controller Nov 21 15:04:53 Tower kernel: nvme nvme0: I/O 10 QID 0 timeout, reset controller Nov 21 15:05:22 Tower kernel: nvme nvme0: Device not ready; aborting reset

Please post full diags: Tools -> Diagnostics

Then it should be OK, syslog doesn't show the last hours because of the previously mentioned spam.

Docker image is corrupt and spamming the log, you need to delete and re-create.

Mostly to satisfy my curiosity, and sorry for being off topic since this bug report doesn't have anything to do with xfs, I also tested earlier Unraid releases: v6.2.4 - kernel 4.4.30 - doesn't mount, only read-only mount is possible: Nov 21 11:33:21 Tower9 kernel: XFS (md2): Superblock has unknown read-only compatible features (0x4) enabled. Nov 21 11:33:21 Tower9 kernel: XFS (md2): Attempted to mount read-only compatible filesystem read-write. Nov 21 11:33:21 Tower9 kernel: XFS (md2): Filesystem can only be safely mounted read only. v6.3.5 - kernel 4.9.30 - mounts normally with a warning: Nov 21 11:38:54 Tower9 kernel: XFS (md2): EXPERIMENTAL reflink feature enabled. Use at your own risk! The warning remains until v6.6.7 with kernel 4.18.20 where it mounts normally without any warning, since I only tested one release from each v6.x series it's likely the warning was removed on kernel 4.8 series.

Also, and I was waiting for the diags to confirm, but if you don't have ECC RAM first thing to do now is to run a memtest.

Controller is being detected correctly but no devices are connected, both ports report link down: Nov 20 16:01:51 Tower kernel: ata9: SATA link down (SStatus 0 SControl 300) Nov 20 16:01:51 Tower kernel: ata10: SATA link down (SStatus 0 SControl 300) If no devices are detected by the controller bios they won't also be detect by Unraid.

What filesystem? If using xfs they won't mount because of having the same UUID, but it can be changed on one of them.

We need the diags and the name of the share you are copying to.

It needs to be formatted, next to the array start/stop buttons.

Liked mentioned you should have posted diags but need to check filesystem on that disk: https://wiki.unraid.net/Check_Disk_Filesystems#Drives_formatted_with_ReiserFS_using_unRAID_v5_or_later It would also be a good idead to convert all remaining reiserfs disks.

You can use ddrescue on disk2 and disk1.

Those files are corrupt and will need replacing, would still like to see full diags when it's done.

It wasn't used on the command but it was used for the format, so possibly it's the default now: I already posted earlier that a xfs drive formatted with v6.8 mounts normally with v6.7

Yes, but that's not on disk.cfg, you can create a script with the user scripts plugin and have it run at array start.

Copy some data and run a couple of parity checks, there should be always 0 sync errors.