pervel

My issue was solved by replacing faulty RAM modules. If your RAM is not faulty, then I guess you have a different issue. You're probably better off starting a new thread. 😊

Thanks! I guess I will just go ahead and disable the scheduled trim then.

Aha! I did not know that. But now I'm confused because I don't see the dynamix trim plugin installed anymore. Did that get uninstalled in an upgrade? I do however still see SSD TRIM Settings in the Scheduler: I thought that was part of the plugin actually. So do I now simply disable the TRIM scheduling?

I just got two Samsung 870 QVO 2.5" SSD and set them up in a new pool. I'm just curious if the trim function will be run automatically on the new pool just like on the original cache pool? Or do I have to do something special to trigger it? Also, they are set up in a BTRFS raid1. Will trim be performed on both drives?

I have now also tested with vdisk using cache='none' again. This time without any errors. Yay! I think I can finally conclude that my problems were all hardware related and that new RAM modules have fixed the problem - at least for now. It is still quite strange to me that all of my four RAM modules apparently failed. That suggests an external cause. But I have no clue what that cause might be. I guess I just have to wait and see if it happens again.

I've installed the new RAM. So far that really seems to have helped. I'm getting none of the BTRFS errors from before. 😀 So I guess the conclusion so far is that it really was bad RAM. Of course that worries me since it's hard to believe all 4 RAM sticks failed without some external reason. I have not yet tried to change my vdisks back to cache='none'. I would like to see the system run stable for a few days straight first. Thanks for the assistence, @JorgeB!

Sadly, I did get a couple of BTRFS errors today even with these changes. But far less than before where the log was filling up with them. So I don't know what I conclude right now. I'm getting new RAM sticks today. I will try those and report back.

I think I have found the problem! It's completely unrelated to any RAM issues. It has to do with how I have defined my vdisk. For a long time I have been using the following definition: <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/mnt/user/domains/WinVPN/vdisk1.qcow2'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> Notice the line with cache='none'. I have changed that from the default cache='writeback'. I honestly cannot remember why I did that. I think I read somewhere that this had better performance. However, this appears to be the reason for all the BTRFS errors. If I change back to cache='writeback', I no longer get any BTRFS errors. I'm happy to change back to the default but I do wonder if this is perhaps a bug?

But that's what I did. And still the same errors.

I did the following: Copied the vdisk from cache to array Changed the VM to point to the new vdisk location on the array Ran the VM. Did not get any errors in the log Copied the vdisk back from array to cache Changed the VM back to point to the vdisk location on the cache Ran the VM. Got the same BTRFS errors as before all pointing to the inode for the vdisk What can I learn from this? The array is formatted XFS and not BTRFS. Should XFS give the same kind of errors if the file is damaged? Btw, the VM appears to run just fine despite these errors. But maybe that's just luck.

I've run 4 passes of memtest on the remaining good RAM stick. It gives no errors. I've uses these 4 sticks for 2 years now without issues. So it is really strange. There are no errors reported when running scrub. But when I run the VMs, I get BTRFS errors. The inode in the error message does indeed belong to the virtual disk file for the corresponding VMs. These files were copied over from the SSD at the time when I was still using the bad RAM sticks. Should that matter? I plan to buy new RAM sticks today. I really hope there are no other hardware issues present. But it is worrying that 3 sticks have failed.

When I ran the scrub I got BTFS errors that referenced paths to files on the cache such as: Nov 22 21:33:06 Basse kernel: BTRFS error (device dm-1): bdev /dev/mapper/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 763, gen 0 Nov 22 21:33:06 Basse kernel: BTRFS warning (device dm-1): checksum error at logical 264171896832 on dev /dev/mapper/nvme0n1p1, physical 135347519488, root 5, inode 20179, offset 159330914304, length 4096, links 1 (path: domains/GamePC/vdisk2.qcow2) After deleting those files I no longer get scrub errors. But I still get errors when trying to run a VM from the cache I get a more generic error such as: Nov 22 21:42:06 Basse kernel: BTRFS error (device dm-1): bdev /dev/mapper/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 780, gen 0 Nov 22 21:42:08 Basse kernel: BTRFS warning (device dm-1): csum failed root 5 ino 20188 off 10248269824 csum 0xbf691df4 expected csum 0xd7cd4596 mirror 1 Can you explain what is going on? Are somes files still damaged? Or is the physical SSD damaged? What is the best way forward for me? I should note that it's only the two big Windows VMs that give these errors. I have a number of Linux VMs that don't seem to give errors. But they are also noticeably smaller.

I don't understand what's going on. I have now run memtest on each of the 4 RAM sticks. 3 of them showed errors. Only one did not. What are the chances of that? I wonder if this means there is something else wrong with the computer. Then I started Unraid with the single good RAM stick I deleted the files in syslog that scrub complained about. Then ran a new scrub and it finished without reporting errors. However, when I start both of my Windows VMs, I still get loads of BTRFS errors in syslog. But scrub says nothing. How can this be? basse-diagnostics-20221122-2152.zip

Yes, I will do that. Thanks for your help.