Modern versions of Unix are more adjustable than they used to be
One of the slow changes in modern Unix over the past ten to fifteenyears has been a significant increase in modularity and with it howadjustable a number of core things are without major work. This hasgenerally not been something that ordinary users notice because ithappens at the level of system-wide configuration.
Undoubtedly this all sounds abstract, so let's get concrete. Thefirst example here is the relative pervasiveness of PAM . Inthe pre-PAM world, implementing additional password strength checksor special custom rules for
How writes work on ZFS raidzN pools, with implications for 4k disks
There is an important difference between how ZFS handles raidzN poolsand traditional RAID-5 and RAID-6 systems, a difference that can haveserious ramifications in some environments. While I've mentioned thisbefore I've never made it explicit and clear, so it'stime to fix that.
In a traditional RAID-5/6/etc system, all stripes are full width, iethey span all disks (in fact they're statically laid out and you canpredict which disks are data disks
Why we're switching to SSDs for system disks
A commentator on my entry on our future fileserver hardware asked a good question, namely why we'replanning to use SSDs for system disks. This is actually likely partof a general shift for us (we've already done it on some new servers).The short version of why is that it is less 'why' and more 'whynot'.
SATA hard drives seem to basically have a floor price. 3.5" or 2.5",small or moderately large, you simply
Wikitext needs a better way of writing tables
For the most part good wikitext dialects do a pretty good job ofletting you write formatting stuff in a way that looks and feels verynatural. Markdown is an excellent example here; much of its formattinglooks basically how you'd write it in a plain text document such as aplaintext README or email message (and this is by deliberate design).I will semi-modestly claim that DWikiText (my wikitext dialect herein DWiki ) does likewise, again by design, although it probably isn'tquite as
Revising our peculiar ZFS L2ARC trick
Here is a very smart question that my coworkers asked me today: ifwe have an L2ARC that's big enough to cache basically the entireimportant bit of one pool , is there much of apoint to having that pool's regular data storage on SSDs? After all,basically all of the reads should be satisfied out of the L2ARC sothe read IO speed of the actual pool storage doesn't really matter.
(Writes can be accelerated with a ZIL SLOG if necessary.)
Our likely future backend and fileserver hardware
At this point we've finalized almost all of the hardware for renewingthe hardware for our fileserver infrastructure ,unless something terribly bad turns up ( which is always possible ). So today I feel like talking aboutwhat hardware we're choosing and the size and scope of our project,partly because it seems uncommon to do this sort of thing.
The base backend hardware is a SuperMicro X9SRH-7TF motherboard with 8G of (ECC) RAM, an Intel E5-2603
Naming disk devices: drive IDs versus drive locations
From my perspective there are two defensible ways of naming disk drivesat the operating system level. You can do it by a stable identifiertied to the physical drive somehow, such as a drive serial number or WWN , or by a stableidentifier based on its connection topology and thus ultimately thedrive's physical location (such as the 'port X on card Y' style ofname). I don't want to get into an argument about which one is 'better'because I don't think
An open question: part uniformity versus unit cost
We're in the process of renewing the hardware for our fileserverinfrastructure and at this pointwe've basically settled on the motherboard we'll use for both theiSCSI backends and the fileservers and the hardware for the iSCSI backends; the backends willbe built around a 3U case with 16x 3.5" drive bays on the front and2x 2.5" drive bays on the back (and dual power supplies and variousother bits). As we were discussing things today, we
If you're on the IPv4 Internet, you really are in public now
Once upon a time it was possible to feel that your machines weresomewhat private and obscure even if they had public IP(v4) addressesand were on the Internet. It wasn't quite true but it was mostly truebecause what scanning there was was haphazard and slow and random. Youmight get poked sooner or later, especially for common things like SSH,but that was just from background noise and people trying to get lucky.
The first clear and public cracks in this came last year with someanonymous
Old and new addresses and spam
In response to an aside wondering how fast spam fell off for disusedemail addresses , Henry Spencer wrote me tomention that his older address (disused now for many years) gets a lotmore spam than his current address. I've been thinking about this sincethen and I've realized that I implicitly divide disused addresses intoat least two different categories. Let us call these the old activeaddresses and everything else.
Put simply, the old active addresses were actively and generallywidely used on the Internet in what