Fstab is a nightmare from which i am trying to awake

dankblog! 2023-06-07, 0628 EDT, at the danktower

mount(2) is surely one of the messiest system calls (i mean ioctl(2) obviously has it beat in terms of sheer area, but that's pretty much the point of ioctl(2)). it's grotesque and grows more rather than less grotesque over time. would-be heroes have several times volunteered as tribute, offering rewrites such as fscommit and fsmount, just two of the more recent attempts to improve on this blight. all have proven still more grotesque than mount(2). and so we beat on, boats against the current, passing a page or more of good ol'

const void *_Nullable data

to be interpreted as it will by different filesystems. "Typically it is a string of comma-separated options." that's the kind of spec i like to code against.

i recently extracted 16 hard drives from my workstation, moving them into a computer in my livingroom, and now must access all my shit over nfs. this has sucked just as much as you'd expect anything involving nfs to suck, as i've winnowed my way towards the magic set of options that ensure i use nfsv4 over tcp and recover reasonably most of the time, in exchange for silent and unrecoverable errors a very small part of the time, i think. anyway, anyone who knows me knows i'm militantly pro-systemd, not because systemd is any inspired or even pleasant bit of software, but because it's so obviously superior to the abjectly unacceptable non-systems that preceded it. so i figure no way has Lennart the P not extended his CamelCase empire to specifying mounts, and go read up on systemd.mount(5), and write up my NFS mounts that way. kertwang! such files are not intended for human use, and general best practice is to still use /etc/fstab, mainly (so far as i can tell) because no one knows about systemd.mount(5) files and even fewer people want to deal with them when /etc/fstab has been getting the job done since BSD 4.0, even if I wouldn't want to bet money on those two numbers at the end of lines (dump? pass? but what does it mean to dump? i think possibly something involving tapes?! all i'm certain of from the top of my head is that if i get it wrong, i'm complexly and esoterically fucked).

so then...why have them at all? you're literally training people to continue inspecting only /etc/fstab. aieee.

that we have not really improved upon the horrible sequence of openssl(1) questions in thirty years is an indictment of our entire profession. what's YOUR Organizational Unit, my sister in Christ?

if you've got a couple of computers, you can probably easily watercool them all with a single MORA3, and forgo radiators in the individual machines. i've moved entirely to liquid for this reason. make sure you have quick disconnects so that you can pull individual machines from the loop; there is only one product worth buying, and it is the Koolance QD4.

i'm hopefully moving my big work project to a maintenance state this month, and going on something like a sabbatical for the remainder of the year. i desperately need to edit down my novel and bring it to publication. i furthermore stumbled upon the six chapters i'd written of High-Performance Systems Programming, which i'd thought lost, and that got me all revved up about finishing that effort. my io_uring reference recently hit the top of hackernews, and rightly so—io_uring is the shit and my absolute jam. moving past Stevens means writing about multicore, SMT, cgroups, namespaces, kqueue, eBPF, XDP, DPDK, spdk, great gobs of shit. it needs doing! and there can't be too many people better suited to do it IMHO.

work work work work work work work work work work work work work work work work work

hack on!

previously: "eXtended disquisitions pertaining to eXpress data paths" 2023-04-20