JorgeB

2/3 hours per TB, you can also see the estimated time for that specific drive in the SMART report, this line: Extended self-test routine recommended polling time: (1128) minutes. Possibly but not necessarily, different firmwares have sometimes different behavior regarding on how they handle bad sectors.

I hope you also stopped overclocking your RAM.

Old age is just the type of attribute, while a non zero attribute for offline uncorrectable is never good it doesn't mean that the disk is failing, wait for the extended SMART test, if it passes disk is good for now, and as long as that value doesn't increase it would be fine.

Btrfs itself would catch that, and generate an i/o error, not Unraid/md driver. It doesn't, it's btrfs feature, you'd get an i/o error, i.e., the file would fail to copy/read and the reason would be logged on the syslog, e.g.: Oct 6 09:27:42 Test kernel: BTRFS warning (device md1): csum failed ino 266 off 739328000 csum 1517421248 expected csum 4056982075

Not directly, if you want to monitor that you can also use the script, I don't because bit rot is extremely rare and it would be detected on the next parity sync (by there being some unexpected sync errors, that you could then investigate) or when you next tried to access that file (if you try to access any file and btrfs detects it's corrupt you'll get an i/o error, i.e., the file will fail to read/copy, that is normal behavior with any checksummed filesystem so you're not unknowingly fed corrupt data but are alerted that there is a problem, the checksum failed error would be logged on the syslog).

If direct i/o doesn't help I don't know of anything else you can do other than trying different hardware, ideally hardware you already have availble, and that doesn't necessarily mean faster/better hardware, just different, though since SMB is single thread CPUs with better performance on a single core are usually better, i.e., a 3.5Ghz quad core is usually faster than an 8 core 2.5GHz CPU for this.

No, any read errors/writes errors on array devices are reported by the md driver and can also be monitored, independent of the filesystem used, cache devices or pools don't use the md driver, and any errors are not monitored/reported in the GUI, if you notice there's also an error column for cache devices but it always shows 0, even if there were errors, and again this is filesystem independent, I made a request some years ago that the error column could be used to report at least errors for btrfs devices/pools, since that can be get easily by reading the output of "btrfs dev stats", but it's not been implemented so far.

SMART shows a recent UNC at LBA error, if it happens again you should run an extended SMART test first. You can skip the preclear.

Like mentioned there's always some overhead when using user shares, but the amount of the overhead can vary a lot with config/hardware used.

Cache is balanced now but the syslog is being spammed with ACPI errors, see here for how to fix then reboot and post new diags.

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

Nothing logged suggests a hardware issue, run the server as a basic NAS for a couple of days, boot in safe mode and disable all dockers/VMs, if it still locks up like that you need to start swapping some hardware.

Any read/write errors for array devices will be reported by the standard Unraid notifications, but won't be reported for any pool member. Yes. If a device drops from a redundant pool and you reboot (bringing the device back online) you can see corrected errors on the log, since btrfs will auto-correct any detected error during a read, but it's best to run a scrub so all corrections are done asap, in case another device drops/fails and also to check that all errors were corrected. Yes, just add the other mount paths, I have a scrip monitoring all my pools, array devices I don't see the need since you'll be warned about any read/write error by Unraid, though the script would warn also if any corruption error is found but that would be also noticed by an i/o error (if trying to access/copy that file).

Please post the diagnostics: Tools -> Diagnostics

There's always some overhead when writing to an user share, but for some reason some users see a much more large impact tan others, e.g. I get around 800MB/s vs 1GBs writing to user vs disk share, enabling direct i/o helps in some cases. Because first Unraid caches the writes to RAM, it will eventually drop to device speed if it's a large enough transfer.

Please use the existing UD plugin support thread:

You should create a bug report about this.

Do that and then re-run the balance.

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

Can't comment on the disk issues since the diags are after rebooting but you also need to check filesystem on disk7.

I have a couple of those, they work fine with Unraid.

It's not a device problem, there's filesystem corruption, and if there's no other other explanation for the sync errors both are likely caused by a hardware issue, like the overclocked RAM you're running, which is known to corrupt data in some Ryzen systems, see here.

It would be better, difficult to quantify by how much though.

You won't get a notification for most issues with a pool, that's why it's important to run a monitoring script link explained in the link above.

You should post this on the Nvidia plugin support thread: