JorgeB

It doesn't, trim it's not supported for array devices for now, but even without it trim performance can still be good, recommend a good quality SSD like the Samsung 860 or 870 EVO, Crucial MX500, etc, I use the 860 EVO, and if possible a faster and more endurant device for parity, I use an NVMe device, don't forget that parity will have has many writes as all the array devices combined.

Yes, unless you get some quirky model, trim won't work though, so there might be some write performance degradation over time, I have a small SSD array and so far it's still performing well, even after every device was overwritten multiple times.

Docker image is on disk1, and disk1 is full: Filesystem Size Used Avail Use% Mounted on /dev/md1 2.0G 2.0G 24K 100% /mnt/disk1

It's a SAS drive.

smartctl -x /dev/sdb If it doesn't work swap cables with another drive, if it still doesn't it's likely a drive problem.

Cache replacement is broken in v6.9, I did a bug report some time ago but it's still not fixed.

Correct, the more space you use the more accurate the reported free space will be.

Use xfs or ntfs.

If the emulated disk is mounting and data looks correct you can rebuild on top and it will preserve the data, and you can do both disks at the same time: stop array unassign both disks start array stop array re-assign both disks start array to begin data rebuild and parity sync.

That's likely the target filesystem no supporting permissions, what file system? Though data should still be copied correctly.

Besides some data corruption the filesystem on disk1 is also corrupt, so you should backup and re-format, if you still have read access no need to use the recovery options, unless you want to recover the corrupt files, since you might no be able to copy those.

Two correcting checks, one after the other, without rebooting.

There are some recovery options here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=543490

It does look like a connection or power problem, replace cables/slot and post new diags after array start.

I only see a non correcting check in the diags, run two correcting checks without rebooting, then post new diags.

Both disks are disabled, but disk10 is mounting according to diags, if contents look correct you can re-enable both disks at the same time. P.S. both DIMMs are installed in the same channel, for best performance and stability use different channels.

You'll only have 240GB usable, if you update to v6.9 you'll get the correct free space. Also cache floor is set to 20TB, setting for that is in KB, so if you want 20GB remove 3 zeros, or type 20G

Correct, free space will be incorrect, though it will get better as you fill up the pool.

Yes, you can wipe it with blkdiscard

That's normal and how it always been, you can enable disk shares to see them. Despite what the GUI shows pool is currently using a single device: Data Metadata System Id Path single single single Unallocated -- -------------- -------- --------- -------- ----------- 2 /dev/nvme0n1p1 33.00GiB 1.00GiB 32.00MiB 897.48GiB Stop the array, unassign the other device (nvme2n1), start array, stop array, re-assign that device, start array, if successful it should auto balance to raid1.

Krusader creates all the folders in the first available disk before starting the transfer, then split level will override allocation method.

Then the disk is fine for, just keep monitoring.

You have disable disks without parity, which suggest you did have a parity assigned at some point and it wasn't correctly removed, you need to do a new config to reset the array, then just assign all disks as they were, if there's any unmountable disk post new diags.

Does it crash for disk2 only? Post the diags after it does.

It won't freak out.