Notices by Garrett Wollman (wollman@mastodon.social)

@xenotar I have no idea, all I see is how long it takes (or if it runs out of space and fails).

I remember when GCC took as long to build as rust does now.

On a 16-MHz processor with 16 MiB of RAM.

I have a very simple solution to the "data broker problem": simply outlaw them. There is no reason a free society should tolerate their existence.

@dalias @ireneista @rysiek 20 years ago, though...

Really interesting new post by Derek Lowe today https://www.science.org/content/blog-post/adenovirus-vaccine-problems-explained highlighting new research into the immunological mechanism that caused rare adverse events in adenovirus-vector COVID-19 vaccines (and as Derek explains, the mechanism is likely to explain other rare thrombocytopenia syndromes). Summary of the summary: a somatic mutation in a small number of B cells results in an antibody to an adenovirus protein that cross-reacts with a protein involved in blood clotting.

Saw a display ad just now for "cat rentals" but unfortunately I think it was for the heavy-equipment company officially known as Caterpillar Inc.

ZFS fun at work today. `zfs rollback` is very very slow. What turned out to be 1000x faster was:
* delete all intermediate snapshots
* zfs rename badfs badfs-bad
* zfs clone badfs-bad@good-snapshot badfs
* zfs promote badfs
* zfs destroy -r badfs-bad

My guess is that `zfs rollback` is synchronous and we were stuck waiting for the blocks to be freed before it would return. (I chose an intermediate snapshot as the first rollback target just in case, and it took about 45 minutes.)

@dr_a @munin @JessTheUnstill The idea of the gift economy only works if the labor involved is being paid for by someone else, for their own purposes. That was the kind of milieu RMS was soaking in: everyone's labor was being paid for by the US government, and the software was just an externality of making some other thing (weapons, Ph.D.s, supercomputers, CAD tools, etc.). As a mechanism to foster cooperation toward a shared goal, it's fine. It doesn't generalize to the broader economy.

@dalias @job This is going to hurt on directory lookups (directory implementations are optimized for ca. 10³ entries). On the other hand, NFS client path traversal is lockstep so you're going to get N×RTT where N is the number of directories in the oath. (Plus another RTT for the actual read RPC.) Large files with an index that can be held open across multiple requests will perform much better. In theory a custom NFS client that didn't go through namei() would avoid the pipeline stalls.

@nixCraft I have been trying to decrease my exposure to tech this whole year, and it's actually *hard* to do now, because a lot of tech companies are officially classified as something else. An "ex-tech" index fund still has Meta and Google in it because those are considered advertising companies, not "tech". A "social" fund has, I think, all seven of the profoundly antisocial "Magnificent 7".

@dalias @adapalmer You could build an artificial limit in the motor controller, but the torque in general is just a consequence of it being an electric motor and thus having a nearly flat torque curve.

@fesshole I'll do that for literary characters.

@feld We've always set up gmultipath just because it was the easiest way to label the drives by physical location. But having read up on the weird-ass way these expanders are set up, I definitely want to do more work to make sure we're not accessing the drives over a congested link!

My guess is that the Data60 shares its IOM design with a larger enclosure -- I think they have a 90-drive one? -- where both expanders are equally, or more nearly equally, oversubscribed. But anyway, this suggests that there's not much point in connecting more than 10 lanes per host.

This also raises the question of whether #FreeBSD can distinguish between the short path, HBA to IOM to disk, and the longer and lower-bandwidth path, HBA to IOM-A to IOM-B to disk.

I spent a while reading the manual the other night, particularly staring at the block diagram. Each IOM has 24 host-facing lanes, 20 drive-facing lanes, 3 lanes of cross-connect to the other IOM, and 1 lane for the enclosure service processor. The drive-facing lanes are then split evenly, 10 lanes each to 2 expanders -- one of which services only 9 drives and the other of which services the remaining 51. And they don't tell you which slots are the undersubscribed ones. WTF?

Big Storage on #FreeBSD question: suppose you have eight-lane LSI/Avago/Broadcom SAS card (mpr(4)) and a WD Ultrastar Data60 enclosure. If you connect both miniSAS connectors on the HBA to the same IOM on the enclosure, does the HBA actually treat it as a single eight-lane link or is it functionally indistinguishable from connecting each four-lane cable to a different IOM? (We have a decent number of these, despite some peccadilloes it's been our preferred JBOD enclosure for some time.)

`camcontrol smpphylist` conveniently gives the #FreeBSD device names associated with WWNs it knows about, so for example if you run that command against a drive, it will show you the device names of all the other drives on that same expander. If I look at, say, `da5` on one server, it tells me that it's on the expander that is only wired to nine drives, which happened to end up being assigned `da1` through `da10` except `da2`.

And if you look at the WWNs, you can clearly see ports 0-23 are connected to the host ports on the back panel -- right now the one I'm looking at only has four lanes wired. Then ports 24-43 are wired to the two drive-side expanders, ports 44-46 are the cross-connect to the other IOM, port 47 is unconnected, and port 48 is the service processor.

Ok, so I've figured out a bit more about how to figure out the topology of these things under #FreeBSD, using everyone's favorite utility, camcontrol(8)!

The key is that there are six SAS expanders in these boxes: each IOM has one on the host side and two on the drive side -- but the enclosure service processor is connected to the host-side expander. So, if you do `camcontrol smpphylist sesX` you'll see the SAS neighbors of all 48 ports of the host-side expander of that IOM.

That information *does* exist, in the protocol, at least for drives: `smartctl -l sasphy` on a drive will tell you the WWPN of the drive and of the expander it's attached to. But this is now getting a lot more involved than I expected it to be.

It would be great if someone smarter than me who actually knew the protocol could implement a tool that would explore the SAS topology and output it as a graph in a standard format.