JorgeB

Cache="prefer" moves from array to cache, and your cache is now full, you want cache="yes" for that share, see the GUI help.

You can stop it after a single error, it confirms RAM is the problem.

That looks like an Nginx problem, and outside my knowledge, maybe someone else can help, rebooting should fix it, but parity check will restart.

You can try and get extra SATA cables if it's a modular PSU, or just get a new one with enough cables, a new chassis is also an option, budget allowing.

If the dropped disks are OK, and you can run a long SMART test to be sure, you can do a new config with those disks also assigned, to any slot, then just re-sync parity.

SATA splitter should be used for max 2 drives, more than that can easily go over the max 12v rating for a SATA plug, 4.5 Amps.

Can't see what happened to disk13 since it was pre-reboot, but at the moment there are errors on 3 disks at the same time, this suggests more a cable/power issue, do disks 8, 14 and currently unassigned ST2000NM0001_A2_Z1P16K7F0000C229EX7U_35000c50040fbab3b share something in common, like a miniSAS cables, power splitter, etc?

Don't start like that or that device will be wiped, if Docker/VM services are using the cache pool disable them, unassign all cache devices, start array to make Unraid "forget" current cache config, stop array, reassign all cache devices (there can't be any "all data will be deleted" warning), re-enable Docker/VMs if needed, start array.

Yes, that's fine, assuming the controller itself is good quality, the 2 port Asmedia chipset usually works great.

It's still supported, driver was replaced with the out-of-tree version, not removed.

I forgot there's a FAQ entry about this.

The Asmedia 106X 2 port controller works well, any Asmedia with more than 2 ports will have a SATA port multiplier and that's not recommended, not clear if you mean 2 ports + external port, or 2 ports total and one can be external. Any connected storage device counts, doesn't matter if it's connected by SATA, USB, eSATA, etc eSATA would be better, but avoid cables longer than 1m. That's really depends on what you need to use it for, for Dockers 20GB should be more than enough, any user shares can use cache or not, it's up to you.

That's almost certainly a failing disk, would need SMART report to be sure.

Mover won't overwrite files, even if older, delete the older one.

It does look like a disk problem, you should run a long SMART test on disk1, and do the same for disk2.

Feb 18 20:11:49 Tower kernel: sd 11:0:0:0: [sdc] Unsupported sector size 520. Unraid doesn't support a 520byte sector size, you can reformat the disks to 512byte sectors with sg3_utils

Try the diskspeed docker to check if all disks are performing normally.

You're using a controller with a SATA port multiplier (or it's connected to one) and these are not recommended for various reasons, in this case it keeps resetting the disks: Feb 18 23:22:33 Tower kernel: ata10.00: failed to read SCR 1 (Emask=0x40) Feb 18 23:22:33 Tower kernel: ata10.00: failed to read SCR 0 (Emask=0x40) Feb 18 23:22:33 Tower kernel: ata10.01: failed to read SCR 1 (Emask=0x40) Feb 18 23:22:33 Tower kernel: ata10.02: failed to read SCR 1 (Emask=0x40) Feb 18 23:22:33 Tower kernel: ata10.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen Feb 18 23:22:33 Tower kernel: ata10.00: failed command: READ DMA EXT Feb 18 23:22:33 Tower kernel: ata10.00: cmd 25/00:40:80:76:04/00:05:00:00:00/e0 tag 10 dma 688128 in Feb 18 23:22:33 Tower kernel: res 50/00:00:3f:86:04/00:00:00:00:00/e0 Emask 0x4 (timeout) Feb 18 23:22:33 Tower kernel: ata10.00: status: { DRDY } Feb 18 23:22:34 Tower kernel: ata10.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Feb 18 23:22:34 Tower kernel: ata10.00: hard resetting link Feb 18 23:22:35 Tower kernel: ahci 0000:01:00.0: FBS is disabled Feb 18 23:22:35 Tower kernel: ahci 0000:01:00.0: FBS is enabled Feb 18 23:22:35 Tower kernel: ata10.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Feb 18 23:22:35 Tower kernel: ahci 0000:01:00.0: FBS is disabled Feb 18 23:22:35 Tower kernel: ahci 0000:01:00.0: FBS is enabled Feb 18 23:22:35 Tower kernel: ata10.01: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Feb 18 23:22:36 Tower kernel: ahci 0000:01:00.0: FBS is disabled Feb 18 23:22:36 Tower kernel: ahci 0000:01:00.0: FBS is enabled Feb 18 23:22:36 Tower kernel: ata10.02: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Feb 18 23:22:36 Tower kernel: ata10.00: configured for UDMA/33 Feb 18 23:22:36 Tower kernel: ata10.01: configured for UDMA/133 Feb 18 23:22:36 Tower kernel: ata10.02: configured for UDMA/133 Feb 18 23:22:36 Tower kernel: ata10: EH complete

Reboot, and take the opportunity to move the SSD to one of the onboard SATA ports, if nothing else because the SASLP won't support trim.

Yep, and by CA and related I didn't mean user scripts, since it's been a problem before, not the plugin obviously, but the scripts users have running at array start, but good you pointed it out, by Dynamix or CA and related I meant these: >> ca.backup2.plg - 2019.10.27 >> ca.cfg.editor.plg - 2019.07.07 >> ca.cleanup.appdata.plg - 2019.09.15 >> ca.update.applications.plg - 2020.02.13 >> community.applications.plg - 2020.02.13 disklocation-master.plg - 2020.01.27 >> dynamix.active.streams.plg - 2019.01.03 >> dynamix.s3.sleep.plg - 2018.02.04 >> dynamix.ssd.trim.plg - 2017.04.23a >> dynamix.system.buttons.plg - 2018.09.08 >> dynamix.system.info.plg - 2017.11.18b >> dynamix.system.stats.plg - 2019.01.31c >> dynamix.system.temp.plg - 2019.11.03 fix.common.problems.plg - 2020.02.06 gui-links.plg - 2019.01.19 NerdPack.plg - 2019.12.31 preclear.disk.plg - 2020.02.14 rclone.plg - 2019.11.01 recycle.bin.plg - 2019.04.08 statistics.sender.plg - 2017.09.22 unassigned.devices.plg - 2020.02.09 unassigned.devices-plus.plg - 2020.01.13 unlimited-width.plg - 2020.01.05 unRAIDServer.plg - 6.8.2 user.scripts.plg - 2019.08.17 Fix commons problems can be also added to the safe list, and other like UD the same, I just mentioned Dynamix and CA since it rules out a lot of them.

Cache device dropped offline: Feb 18 12:04:51 Tower kernel: ata11.00: failed to set xfermode (err_mask=0x40) Feb 18 12:04:51 Tower kernel: ata11.00: disabled Looks like one the typical SASLP problems, driver crashed, though it could also be cable related.

There's only one way, though you can go ahead and use -L if it asks for it.

Also, parity is for redundancy, not for backup, if you delete some files or get hit with a ransomware virus parity can't help you either.

Disk going bad is not the same as file system corruption, parity can't help with the latter, the best option here would likely have been to re-enable the disk, instead of rebuilding, in some cases when a disk gets dropped filesystem might get some corruption on the emulated disk.