JorgeB

Please post the diagnostics: Tools -> Diagnostics

Yes, that's the default mode. They do count.

That suggests it's probably a disk issue with Linux, try different disks if that's an option.

Diags are after rebooting so we can't see what happened, but CRC errors are a connection problem, usually a bad SATA cable.

You can do a new config.

Also, if it keeps happening to the same filesystem only it might be worth backing up and the re-creating that filesystem.

Those have nothing to do with the update, there are recent UNC @ LBA errors, you should run an extended SMART test.

Start by running memtest.

That's very strange, don't remember ever seing macvlan issues without that.

Enable this then post that log after a crash.

Não, cache é opcional, SSD ou HDD. Unraid não é raid, cada disco usado no array é um sistema de ficheiros independente, partilhas podem usar vários discos, mas cada ficheiro está sempre num disco especifico. Sim. Não, Unraid usa xfs or btrfs, discos em ntfs podem ser montado com o UD plugin, mas nunca usados no array ou numa pool. Unraid não suporta zfs, embora esteja previsto para o futuro. XFS é o mais adequado para a maior parte dos utilizadores.

Yes, AFAIK there aren't and there ever weren't any issues with the btrfs checksum verification, also I confirmed and that zip file really was corrupt, it gave an error on extraction. And you want me to believe that after using btrfs almost exclusively for the last 4 or 5 years never had any data corruption found (or any other issues for that matter), other than twice after similar events with the devices, it was a coincidence? Or a false positive (which I can confirm it wasn't in this case)? It wouldn't make any sense.

3Gbps is fine for hard drives, just be aware that some 3Gbps hardware is limited to 2TiB max capacity, e.g., LSI SAS HBAs and SAS expanders.

Unfortunately don't see the reason for the crash logged, one more thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

We recommend that scheduled parity checks be non correct, in some rare cases a disk problem during a correcting check might corrupt parity.

Reviving this thread since it happened again, now with a hard drive, a Seagate ST1000LM035, disk had already some reallocated sectors when I began using it for this function, but it passed an extended SMART test and worked fine without any issues for a few weeks, this morning had several emails from last night, first with new reallocated sectors: 18-04-2021 01:21 Unraid Wbackups disk SMART health [5] Warning [TOWER1] - reallocated sector ct is 984 ST1000LM035-1RK172_ZDE5AFTA (sdd) 18-04-2021 01:18 Unraid Wbackups disk SMART health [5] Warning [TOWER1] - reallocated sector ct is 968 ST1000LM035-1RK172_ZDE5AFTA (sdd) 18-04-2021 00:17 Unraid Wbackups disk SMART health [5] Warning [TOWER1] - reallocated sector ct is 960 ST1000LM035-1RK172_ZDE5AFTA (sdd) Then and because I have a script monitoring all btrfs pools for errors, got an email about that: 18-04-2021 01:47 Unraid Status ERRORS on wbackups pool In this case the errors detected were corruption errors: root@Tower1:~# btrfs dev stats /mnt/wbackups/ [/dev/sdd1].write_io_errs 0 [/dev/sdd1].read_io_errs 0 [/dev/sdd1].flush_io_errs 0 [/dev/sdd1].corruption_errs 20 [/dev/sdd1].generation_errs 0 A scrub this morning confirmed the data corruption: root@Tower1:~# btrfs scrub status /mnt/wbackups/ UUID: 9c12f50a-ad56-4a61-934a-4b1ee064cae9 Scrub started: Sun Apr 18 12:26:01 2021 Status: finished Duration: 1:21:57 Total to scrub: 545.20GiB Rate: 113.59MiB/s Error summary: csum=650 Corrected: 0 Uncorrectable: 650 Unverified: 0 Note that this is a single disk btrfs device, so no redundancy to fix data corruption (this is only used as another backup destination), looking at the syslog it identifies the corrupt file, one of several zip files from a remote backup that are synced to that disk: Apr 18 12:30:47 Tower1 kernel: BTRFS warning (device sdd1): checksum error at logical 271712112640 on dev /dev/sdd1, physical 38710136832, root 5, inode 5879, offset 162140160, length 4096, links 1 (path: SageBackups/.stversions/503951269202104071502.zip) So yeah, while this should never happen, i.e., devices shouldn't reallocate sectors without corrupting data, here it is once again proof that it can happen.

Did you change the VM name? I though that bug was already fixed, but apparently not.

Cables can go bad at any time, worth doing to rule them out, could also be a controller issue since that is the single disk on that controller, hence why I suggest swapping. That is IMHO a waste of time and will put another write cycle on it, if you want to test the drive run an extended SMART test. Yes.

Syslog doesn't cover the disk getting disable, but SMART looks fine so unlikely a disk issue, I would swap cables/controller with another disk to rule that out and rebuild on top.

Run a non correcting check, if no more errors are found you're fine.

If there are still macvlan call traces there's still a problem with that, unless they were old, syslog is spammed with NVIDIA errors so more difficult to analyze.

See if this helps: https://forums.unraid.net/topic/76066-vm-settings-change-stuck-at-updating/?do=findComment&comment=705420

Please use the existing support thread: https://forums.unraid.net/topic/4351-cache_dirs-an-attempt-to-keep-directory-entries-in-ram-to-prevent-disk-spin-up/page/46/

Macvlan call traces are usually the result of having dockers with a custom IP address, more info below. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/

The eSATA includes a port multiplier: Apr 17 14:05:41 Tower kernel: ata1.15: Port Multiplier 1.2, 0x197b:0x0562 r0, 2 ports, feat 0x5/0xf That's my guess on what's causing the problems, not even sure the onboard AMD SATA controller suports port multipliers, Intel doesn't.