avidamoeba

nvidia: loading out-of-tree module taints kernel

Requires kernel-level access. Also AMD is "releasing mitigations," so is it "unfixable?"

This is a completely different category of device.

You're making me nervous.

But then again, all my Pis are OpenWrt now which barely writes, so I'm probably fine. 😅

Any failures of SanDisk Extreme Pro / Samsung Evo Plus?

I buy the redundancy argument. I'd still use ZFS for that if possible though. 😂 All my machines use mdraid 1 for their system drives but now that I know enough about ZFS, I'd likely use it on root next time around.

BTW in my anecdata I've yet to have a failure on any of my SanDisk Extreme Pro SD cards. I have 4 in active use on different Pi 4s. The oldest one is in use since 2018-ish. It used to be a NAS till 2022 so roughly 3-4 years of 24/7 use with a bog-standard OS. It's now running OpenWrt which does fewer writes.

That wouldn't solve the problem though would it? It might make it less likely to fail but there's still significant downtime if there's no hot spare for this USB drive.

Why would it lock up? ZFS will use as much RAM as you give it and it doesn't seem CPU-bound unless you turn on encryption. It's not a cluster FS like Ceph. Why do you expect ZFS to lock up and Btrfs not to?

I would try it. My only issue is I have no idea how to set it up on root on a Pi. Perhaps there's docs somewhere. If had to setup a new Pi with Pi OS/Debian/Ubuntu today I'd definitely try it. Most of my Pis are running OpenWrt though.

I used it on a Pi 4 in 2019 for an USB-connected mirror and it worked well. Unencrypted throughput was upwards from 200MB/s. Encrypted throughput dropped down to under 100MB/s due to insufficient compute. The Pi 4 is a powerful computer and the Pi 5 even more so. Pi 3 and older, not so much.

Perhaps the best answer by far is ZFS but I don't know how much pain it is to set it up to boot from on a Pi. The easiest to setup is probably LVM.

With ZFS you can trivially keep a hot spare even over the network. Just tell syncoid where to replicate.

Yeah, you're right, if it's meant as disks-only, then TPM is the easy solution.

I think SSH unlocked LUKS at boot might be a decent compromise, with the SSH server at a different physical location.

I mean, TPM-locked machine with all the other parts configured correctly should be reasonably secure. It would boot without interaction and be available on the network. It would require a sophisticated and motivated actor to find a vulnerability in one of the systems in the boot chain to get in. That's probably good enough for preventing data leaks from theft. But the user has to make sure the whole boot chain is configured securely.