ZFS DVA offsets are in 512-byte blocks on disk but zdb misleads you about them

Yesterday I asserted that ZFS DVA offsets were in bytes , based primarily on using zdb to dumpa znode and then read a data block using the offset that zdb printed.Over on Twitter, Matthew Ahrens corrected my misunderstanding :

The offset is stored on disk as a multiple of 512,see the DVA_GET_OFFSET() macro, which passesshift=SPA_MINBLOCKSHIFT=9. For human convenience, the DVA isprinted in bytes (e.g. by zdb). So the on


ZFS DVA offsets are in bytes, not (512-byte) blocks

In ZFS, a DVA (Device Virtual Address) is the equivalent of a block address in a regular filesystem. Forour purposes today, the important thing is that a DVA tells youwhere to find data by a combination of the vdev (as a numericindex) and an offset into the vdev (and also a size). However,this description leaves a question open, which is what units areZFS DVA offsets in. Back when I looked into the details of DVAs in 2017, the


A thought on presentational versus semantic HTML

One of the long running argument topics in web design is semantic versus presentational HTML, which is to say a split between writingHTML (and CSS) purely for how the result looks and authoring HTMLthat tries to put its semantic meaning first and then style thesemantic meaning with CSS. There is a wide spectrum between these twopoles, of course, especially once you start caring about issues like(HTML) accessibility. Recently, I had a thought about why this issuepersists and why we don't all write


Getting USB TEMPer2 temperature sensor readings into Prometheus (on Linux)

For reasons outside of the scope of this entry, we recently decidedto get some inexpensive USB temperature sensors (we already have anumber of old, industrial style temperature sensor boxes). What wewound up getting is the PCsensor TEMPer2 ; this modeland PCsensor's USB temperature sensors in general seem to be a quitecommon choice (often resold under some other name). Getting our modelgoing on Linux and getting metrics into our Prometheus setup took some work and headscratching, which I'd like to


Large scale Internet SSH brute force attacks seem to have stopped here

The last time I paid attention to what happened when you exposedan SSH port on the Internet was years and years ago, when I gaveup being annoyed by log messages and either stopped paying attentionor firewalled of my SSH ports from the general Internet. Back then,it was received wisdom (and my general experience) that having anSSH port open drew a constant stream of SSH brute force attacksagainst a revolving cast of whatever logins the attackers couldcome up with.

Recently I set up a Grafana Loki setup that


Using systemd timers to run things frequently (some early notes)

If you're satisfied with running something no more often than oncea minute, /etc/cron.d entries are the easiest approach and what Iuse. But today I wound up wanting to run something more frequently.While there are various ways to do this with various degrees ofhackery, it seemed like a good time to try out systemd timer units .

First we will need our .service unit, which is straightforward:

[Unit]Description=Read sensors[Service]Type=oneshot# Run your

U.2, U.3, and other server NVMe drive connector types (in mid 2022)

The other day I casually looked aroundto see how readily available U.2 NVMe drives were compared to SATA SSDs. In the process I saw somemention of '2.5" U.3' NVMe drives, which was a connector type I'dnever heard of, and did some digging.

The short summary of U.2 is that it's NVMe drives in more orless the 2.5" SSD form factor (although according to Wikipedia, U.2can also deliver two SATA


We now have some 1U servers with U.2 NVMe SSDs and they're okay

Back in early 2021 I wrote about my impressions of NVMe versusSATA (or SAS) SSDs for basic servers . Atthat point I didn't expect us to get NVMe based servers any timesoon, especially for servers not focused on fast storage. Well,times change, and we now have a number of 1U servers with U.2 NVMedrives. These aren't really "basic" servers in our usual sense;instead they tend to be pretty powerful compute servers . But they


On Ubuntu, AppArmor is quite persistent and likes to reappear on you

We don't like AppArmor ,in large part because it doesn't work in our environment; the neteffect of allowing AppArmor to do anything is that periodicallyvarious things break mysteriously (for instance, Evince stops workingbecause your $XAUTHORITY is on an NFS mounted filesystem). We doour best to not install AppArmor at all, and if it gets dragged inby package dependencies, we try to disable it with a heaping helpingof systemd manipulation:

systemctl stop apparmor.servicesystemctl disable apparmor.servicesystemctl

Some notes on Grafana annotations sourced from Prometheus metrics

Grafana Annotations have long been one of those 'I should look into this sometime'Grafana features that seemed potentially useful but not immediatelycompelling, and also a bunch of work to set up. Recently I learned(or re-learned) that you can dynamically generate annotationsfrom Prometheus metrics and other data sources ,and spent some time experimenting with this, not always successfully.As a result, I have some notes and some opinions. I'll start withthe bad news.

Grafana has two sorts of annotations,