JorgeB

Disk was disabled: Aug 26 14:12:51 storage kernel: md: disk10 write error, sector=583032 You stopped the array: Aug 26 14:16:27 storage kernel: mdcmd (38): nocheck cancel You replaced the disk and started the array, disk was unmountable immediately at array start: Aug 26 14:18:25 storage root: mount: /mnt/disk10: can't read superblock on /dev/md10. What you should do here if to first start the array with the emulated disk, before replacing, it would already be unmountable. What it sounds like, it should only be used after a new config if parity is valid, it wasn't in your case since there was a disable disk before the new config.

Are are you copying from/to within Krusader?

I just tested Krusader and as expected it works like the other ones, I coped a small pdf to share set to 100GB minimum free space an it went to disk2:

If this is for farming chia that's what I would recommend, do multiple raid0 pools with 4 or 5 disks max, they can still be all on the same share and if you lose a disk you only lose a small pool.

See help is because btrfs raid5/6 is still considered experimental, it should be used with care, i.e., have backups for anything important.

Usually rsync or midnight commander (mc on the console), but Krusader will work the same, if used correctly.

It won't if it's correctly configured, I never used Krusader but as long as you're really using user shares it will respect the minimum free space for that share.

It does if using the user shares, not with disk shares, once you past the minium free space set it won't start copying anything to that disk, unless like mentioned the split setting is making it go there. It would run out of space, once a file is on an array disk it will never be moved by Unraid to a different one.

It has a real minimum, it just has no way of knowing the size o a file before the copy stars, if you have the minium set to 50GB, have 60GB free and start copying a 100GB file it will copy to that disk and run out of space, that's why you need to set the minium free space to about twice the maximum file size you expect to copy to that share, I seem to remember you already went over all of this with you.

Also I would recommend using smaller pools, especially if it's large capacity disks, much easier to deal with, or any operation needed can take days or even weeks, they can still be all using the same share.

Yes.

Depends on the file size, any file larger than 50GB would still go to that disk and run out of space.

Not if you are using user shares, but split level setting overrides allocation method.

If it's not the PSU the board is the next logical culprit, but also make sure CPU is not overheating.

Go to Settings -> VM Manager and make sure advanced view is enable (top right), then enter valid paths for "Default VM storage" and "Default ISO storage".

It's normal with very recent CPUs, should still find a major problem.

Unraid uses parity to emulate the missing disk, and the filesystem issues remain there, you need to format the disk (after backup) or if you prefer to remove it from the array do a new config without it.

Start by running memtest from the Unraid flash drive boot menu (need to boot in legacy/CSM mode, it won't work with UEFI boot).

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

xfs_info /dev/sdX1 Look for reflink, 1 next to it means enable, 0 disable. Yes, with Unraid each array device is always a separate filesystem.

Yep, it starts over after every reboot.

Did you rebuild disk16? Looking at the syslog it shows you did a new config, parity won't be valid after that, and if that's true it would explain the unmountable disk10, since its generation doesn't match with the one from parity. The drive is always emulated, but was already unmountable first time you started the array.

There's filesystem corruption on disk15, with btrfs best bet is to backup and reformat, you might also try to repair but not before all data on that disk is backed up since it might make things worse.

Diags posted are not the generated zip.

Syslog is just after rebooting, not seeing any errors, grab and post the complete diagnostics (tools -> diagnostics) after the problem manifests itself.