One of the things we generally wind up doing when setting up systemsis configuring their time zone (except for the people who leavetheir servers in UTC). On most Unixes, you can find the availabletime zone names underneath /usr/share/zoneinfo , which has becomesomething of a cross-Unix standard. Once upon a time, it was normalto set these to the name of a time zone, such as 'Eastern', andeven today some things will accept names like 'US/Eastern

Over in the Fediverse, I ran across an interesting question on munmap() :

what does `munmap` on Linux do when address is set to 0? Somehow thissucceeds on Linux but fails on FreeBSD. I'm assuming the semantics aredifferent but cannot find any reference regarding to such behavior.

(There's also this additional note , and the shortversion of the answer is here .)

When I saw this, I was actually surprised that munmap() on Linuxsucceeded, because I expected it

It started with Dave Cheney's Ensmallening Go binaries by prohibitingcomparisons (and earlier tweets I saw about this), which talks about a new trickfor making Go binaries smaller by getting the Go compiler to notemit some per-type internally generated support function that areused to compare compound types like structs. This is done bydeliberately making your struct type incomparable , by includingan incomparable field. All of this made me realize that I didn'tactually know what things are incomparable in Go.

In the language

When I ran into Firefox's interstitial warning for old TLS versions , it wasn't where I expected, and where ithappened gave me some tangled feelings. I had expected to first runinto this on some ancient appliance or IPMI web interface (both ofwhich are famous for this sort of thing). Instead, it was on thewebsite of an active person that had been mentioned in a recentcomment here on Wandering Thoughts . On the one hand, thisis a situation where they could have kept their

It may strike some people as unusual or extreme that we have 340odd NFS mounts on our machines, as I mentioned in my entry on howsystemd can cause an unmount storm during shutdown . There are several levelsof why we have that many NFS mounts on our systems, especially allof the time. First, I'll dispose of a side reason, which is that we don't like conventional automounters (ie,any system that materializes (NFS) mounts 'on demand'). That

One of the things that we discovered fairly early on in our experiencewith ZFS (I think within the lifetime of the first generationSolaris fileservers ) is that ZFS gets veryunhappy if you let a pool get completely full. The situation hasimproved since then, but back in the days we couldn't even changeZFS properties, much less remove files as root . Being unable tochange properties is a serious issue for us because NFS exportsare controlled by ZFS properties, so if we had a full pool wecouldn

A decade ago I wrote some entries about how big our fileserverenvironment was back then ( part 1 and part 2 ). We're now on our third generation fileservers and for various reasons it'sa good time to revisit this and talk about how big our environmenthas become today.

Right now we have six active production fileservers, with a seventhwaiting to go into production when we need the disk space. Eachfileserver has sixteen 2 TB SSDs for user data, which are dividedinto four fixed size chunks

When you add or replace a disk in Linux's software RAID, it has tobe resynchronized with the rest of the RAID array. As very brieflycovered in the RAID wiki's page on resync , this resync processhas speed limits that are controlled by the kernel sysctlsdev.raid.speed_limit_min and dev.raid.speed_limit_max (inKBytes a second). As covered in md(4) ), if there's noother relevant IO activity, resync

I'm currently reading Jim Salter's ZFS 101—Understanding ZFSstorage and performance ,and got to the section on ZFS's important recordsize property,where the article attempts to succinctly explain a complicated ZFSspecific thing. ZFS recordsize is hard to explain because it'srelatively unlike what other filesystems do, and looking back I'venever put down a unified view of it in one place.

The simplest description is that ZFS recordsize is the (maximum)logical block size of a filesystem object