I did not ignore them. I did not mention them, because NTFS was only an example. You are spot on, I also don't trust ext4, xfs....
I do, yes.
That is why I wrote "maybe" for BTRFS. For me personally, it is not battle tested enough. (as we saw...
Mein Tipp: Tue es nicht!
Schau, deine VM zu sichern mit PBS, heisst Blockstorage zu sichern.
Blockstorage zu sichern ist extrem nervig. Es dauert ewigs. Die kompletten 20TB müssen gelesen werden, eine checksum berechnet werden, die veränderten...
Sure. But first tier providers also sometimes do not so smart stuff. That argumentum ad verecundiam is not that strong IMHO. Some would probably even argue that Synology is first tier and look what they do with BTRFS ;)
Simply because it has no...
Even though I believe @somedude, I also agree with @guruevi that there are shady vendors. Mabye shady is a little bit extreme, let me rephrase that to "vendors I would not trust my data".
Just like NTFS is IMHO a shady FS.
For example, I only...
> Battery backup of a single cache still makes it a SPOF
No, it doesn't.
In your scenario, another, prior and unaddressed, failure is required to make NVRAM (and/or other component(s)) a potential single point of failure.
It doesn't make it a...
@alex:
- Dell 'managed' IT - they'll sell Kubernetes (RHEL OpenShift) with an Emulex FibreChannel SPOF proprietary RAID - Ceph is available upon request, but the per-TB licensing cost is (much) higher. I've gotten similar constructions from just...
Just because a vendor does it, doesn’t mean it’s a good idea. Vendors sell some shady stuff and it works, most of the time. Most VMware clusters, even relatively large ones indeed have a storage design that basically resembles DRBD, mdraid or...
like I wrote earlier - the server will calculate and set the CRC for all incoming chunks, and will verify the digest if the chunk is unencrypted (verifying the digest of an encrypted chunk would require the encryption key, which only the client...
I am not 100% certain either. But since we use LLMs to make wild guesses, here are my wild human made guesses: ;)
Course not, incoming data is already optionally encrypted and or compressed. Checksums (verify) are probably not important at this...
You realize how wonky that sounds?
That is like me saying "hey I have this super stable Windows Server here, but unless I run that bat script to release the DHCP every night at 02:00, the NIC won't have an IP the next day".
If you clear out swap regulary you are basically doing the same as not using swap at all. Then you could disable it as well. Now I wouldn't recommend this in general ( again see the already linked pieces by Kernel developer Chris Down for...
IMHO since you already experience IO errors, you are in the danger zone already.
I would disable SWAP on both the VM and Proxmox and see what happens. Reboot and short service interruption is needed anyway.
We recently uploaded the 7.0 (rc6) kernel to our repositories. The current default kernel for the Proxmox VE 9 series is still 6.17, but 7.0 is now an option.
We plan to use the 7.0 kernel as the new default for the upcoming Proxmox VE 9.2 and...
At work ARC is not my concern since my employer is stuck with vmware. The RAM crisis is real though but I was hesitant to enable zram via an ansible-Playbook since I feared potential side effects. Thus I planed to do some benchmarking which is...
I didn't but will definitevly change this asap ;) One should take into account that for zswap you always need physical swap as backing device. For example if you use the defaults of PVEs installer for ZFS you will endup without space for a...
This cannot be done from the GUI.
If this is a non-boot pool, using zpool replace -f is fine.
However, I would recommend specifying the new disk via /dev/disk/by-id/ as well.
If this is a boot pool, you will need to follow the additional steps...
Please note that the need of ECC-RAM for ZFS is quite overblown:
https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
This blog post is quite long (but still good and highly recommended!) reading, the most important point imho...