

best of luck to his replacement, Greg Yoshi


best of luck to his replacement, Greg Yoshi


a cheap docking station with two SATA slots (currently housing hard disks) and putting them together on a RAID0 almost doubles a single one’s performance.
you can buy a 50cc moped and attach a NOS cylinder to it. that might be a fun hobby project, if you’re into it.
but in a drag race, you’re going to get beat by a 10 year old Toyota Prius. because there’s only so much you can eke out of a 50cc engine.
“RAID0 using a cheap 2-slot external enclosure” is one of the more cursed things I’ve ever contemplated. firmly in “just because you can doesn’t mean you should” territory.


short answer: buy NVMe. plug it directly into your motherboard, don’t use an enclosure. forget about wonky RAID0 crap.
longer answer:
SATA SSDs (which you say in the comments below are all you’ve got) are an evolutionary dead-end. they’re SSDs pretending to be very fast hard drives. they end up being bottlenecked by the assumptions that the SATA protocol makes about how fast a hard drive can be.
look at this chart for example. SATA (AHCI) limits a device to having 32 commands queued up at once, which means the operating system needs to jump through hoops in terms of maintaining its own queue of pending reads & writes and issuing them to the device as queue space becomes available.
NVMe raises that limit to 64k, which for any non-server workload is effectively unlimited. the NVMe drive can respond to IO requests pretty much as quickly as the OS can dispatch them.
if you want to know more nitty-gritty details, Scaling ZFS for NVMe is an interesting talk, much of it isn’t specific to ZFS, but instead is about how NVMe devices are so fast that they’re forcing filesystem developers to rethink long-standing assumptions about drives being slow.


at the risk of being “guy who pretty much only plays Factorio recommends you play Factorio…”
you can easily put 50+ hours into a single savefile, especially with the Space Age expansion
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html
it sounds like the kernel is just working around a known CPU microcode bug. it would probably be using the 64-bit RDSEED operation anyway, so disabling the 32-bit option probably doesn’t actually change anything.
also, the kernel’s random number generator is very robust (especially since Jason Donenfeld, the author of Wireguard, took over its maintenance) and will work perfectly fine even in the complete absence of RDSEED CPU instructions.