JorgeB

It's not, most other utils are not reliable with btrfs for used/free space, GUI will show the correct stats for that pool, except total capacity when in raid1 mode because of the different size devices, used/free are correct though, total capacity would be 1TB, with single profile everything will be correct.

Default is raid1, you can convert to single profile to use all the available space.

My first couple of servers are almost 15 years old, both still on the original flash drive, and certainly the only original part remaining on those servers.

Can't see that in the diags, can see overclocked RAM though.

AFAIK Unraid doesn't officially support HA-SMR, also of the current filesystems Unraid supports only btrfs has HA-DMR support, since kernel 5.12+ (currently only Unraid v6.10-rc uses a newer kernel), but not sure if there are any missing options.

Permissions should be fine, not sure about extended attributes, but never used it much.

Minimum space incorrectly set will cause that, as well as split level. There's still a virtual network that will be used if the OS doesn't support server side copy, making it much slower. This is Windows explorer, robocopy also works, others might not. https://wiki.samba.org/index.php/Server-Side_Copy

Nice, also like that it now reports was was done, sync, check or rebuild, would it be too much to ask to also report if the parity check or correcting or non correct?

Neither can we without the diagnostics from when it happened, as for the CRC errors it's usually a bad SATA cable.

NVMe device dropped offline: Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 493 QID 1 timeout, aborting Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 494 QID 1 timeout, aborting Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 495 QID 1 timeout, aborting Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 496 QID 1 timeout, aborting Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 497 QID 1 timeout, aborting Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 964 QID 2 timeout, aborting Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 965 QID 2 timeout, aborting Feb 10 20:55:57 Tower kernel: nvme nvme0: I/O 966 QID 2 timeout, aborting Feb 10 20:56:27 Tower kernel: nvme nvme0: I/O 493 QID 1 timeout, reset controller Feb 10 20:56:57 Tower kernel: nvme nvme0: I/O 22 QID 0 timeout, reset controller Feb 10 20:57:58 Tower kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Feb 10 20:57:58 Tower kernel: nvme nvme0: Abort status: 0x371 ### [PREVIOUS LINE REPEATED 7 TIMES] ### Feb 10 20:58:29 Tower kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Feb 10 20:58:29 Tower kernel: nvme nvme0: Removing after probe failure status: -19 Feb 10 20:58:59 Tower kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Look for a BIOS update, the below sometimes also helps: Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 e.g.: append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference.

You might have repaired the sdX device, that would make parity out of sync, but if you don't remember you still should run a correcting parity check.

Like mentioned disk1 errors are causing filesystem issues, making it go read-only, that will cause some of issues you're seeing.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Pool is only using one device ((sdk) MO0400EBTJV_S0RBNEACC01329), stop the array, unassign the other pool device ((sdl) HSFAC2DA4SUN400G_001644J1TN6A_0QY8TN6A_35000cca04eb91814), start array, stop array, re-assign that device, start array and post new diags.

dm-6 is disk9, check filesystem. After checking file system you can attempt to rebuild, but with that controller I would recommend using a spare disk, so you still have the old one if it goes bad.

Forgot to mention, disabled disk looks healthy, so likely not a disk problem, most likely controller or a power/cable issue.

Diags are after rebooting so we can't see what happened, but those controllers are not recommended for a long time, one of the reasons is that they tend to drop devices without a reason, and unlike suggested the SSD is still connected there.

I would recommend posting in the UD support thread to see if that change could be reversed, so no changes would be needed and it will likely affect other users, alternatively you need to check the mapping for every docker, if you had for example /mnt/disks/Samsung_SSD_850_PRO_1TB_S252NSAG400601K/apppata/container_name it needs to be changed to /mnt/disks/S252NSAG400601K/apppata/container_name

You'd need to get a bigger cache device or set the minimum free space to a lower value, like 100GB, but if a file larger than that comes up copy directly to the array, or check manually that cache has enough free space before starting the copy. Only Windows 8 or newer supports Samba's server side copy using windows explorer.

Likely some UD update. They might still be referencing the old paths in the settings.

UD device is mounted at: unassigned.devices: Mounting partition 'sdn1' at mountpoint '/mnt/disks/S252NSAG400601K'... And you're trying to create the image in Creating new image file: /mnt/disks/Samsung_SSD_850_PRO_1TB_S252NSAG400601K/ Not sure if it's a UD issue or not, but that's the problem, if you can't why this is happening best to post in the UD support thread.

Once the rebuild is done re-enable parity, if it fails to sync post new diags before rebooting.

Value needs to be larger than the largest file you expect to copy there, we usually suggest using twice the value of the largest file you expect to copy, to have some margin. Don't know is OSX supports server side copy with Samba, like Windows explorer does, if it doesn't data will transverse the network and will be much slower. Yes, and if a Windows VM you can use explorer to make a local copy/move like mentioned.

RAID controller BIOS, also keep in mind that RAID controllers are not recommended, this is just one of the reasons.

Disk7 appears to be failing, run an extend SMART test to confirm, there are also read errors on disk1 causing filesystem issues, disk1 looks healthy, issue could be spin down related, run xfs_repair o it and disable spin down for a few days to test.