I recently made public a dtrace script I wrote ,which gives you per file descriptor IO breakdowns for a particularprocess. I think it's both an interesting, useful tool and probablynot quite the right approach to diagnose this sort of problem, soI want to talk about both the problem and what it tells you. Tostart with, the problem.

Suppose, not entirely hypothetically ,that you have a relatively complex multi-process setup with data flowing between thevarious processes and the whole thing is (too

If you ask, many people will tell you that Unix doesn't have ageneral mechanism for suspending processes and later resuming them.These people are correct in general, but sometimes you can cheatand get away with a good enough substitute. That substitute is SIGSTOP , which is at the core of job control.Although processes can catch and react to other job control signals , SIGSTOP is a non-blockable signal like SIGKILL (aka ' kill -9 '). When a process is sent it, the kernel

A commentator left a very good comment on my entry on why I don'tlike HTTP as a frontend to backend transport that points out the security benefits of using a simple protocolinstead of a complex one. That makes a good start to talking aboutthe general benefits of using a non-HTTP transport, beyond the basiclack of encapsulation I talked about in my entry .

The straightforward security benefit (as noted by the commentator)is that a simple protocol exposes less attack surface and will leadto implementations that are

In a comment on yesterday's entry on our IPv6 DNS dilemma , Pete suggested that we duplicate our IPv4'private address space with NAT' solution in IPv6, using RFC 4193addresses and IPv6 NAT. While this is attractive in that it preservesour existing and well proven architecture intact, there are tworeasons I think we want to avoid this (possibly three).

The first reason is simply that NAT is a pain from a technical andadministrative perspective once you're working

In our current IPv4 network layout , we havea number of internal 'sandbox' networks for various purposes. Thesenetworks all use RFC 1918 private address space and with our splithorizon DNS they have entirely internal names (and we have PTRresolution for them and so on). In a so far hypothetical IPv6 future,we would presumably give all of those sandbox machines public IPv6addresses, because why not (they'd stay behind a firewall, ofcourse). Except that this

As I mentioned recently , one of thesimplest ways of expanding your storage space is simply to replaceyour current disks with bigger disks and then tell your RAID system,file system, or volume manager to grow into the new space. Assumingthat you have some form of redundancy so you can do this on thefly, it's usually the simplest and easiest approach. But it hassome potential downsides.

The simplest way to put the downsides is that this capacity expansionis generally blind and not so much inflexible as

I understand that in some places it's popular for servers to gettheir IP addresses on boot through DHCP (presumably or usuallystatic IP addresses). I understand the appeal of this for placeswith large fleets of servers that are frequently being deployed orredeployed; to put it one way I imagine that it involves touchingmachines less. However it is not something that we believe in or do in our core network , for at least two reasons.

First and lesser, it would add an extra step when setting up

Suppose that you are using a dm-cache based SSD disk cache , probably through the latest versions of LVM (via Lars , and see also his lvcache ). Dm-cache is what I'll callan 'interposition' disk read cache, where writes to your real storagego through it; as a result it can be in either writethrough orwriteback modes. It would be nice to be able to find out what modeyour cache is and also to be able to change it. As it happens this

My current programming enthusiasm is a 'sinkhole' SMTP server that exists to capture incoming emailfor spam analysis purposes. As part of this it supports matchingDNS names against hostnames or hostname patterns that you supply,so you can write rules like:

@from reject host .boring.spammer with message "We already have enough"

Well, that was the theory. The practice was that until very recentlythis feature didn't actually work; hostname matches always failed.The reason I spent so much time not noticing this