A brief summary of how ZFS updates (top-level) metadata
As is common in filesystems, a ZFS pool's metadata and data livesin essentially a tree; at the top of the tree is the ZFS uberblockand the actual root metaobject set (which is pointed to by the ZFSuberblock). Because ZFS is a copy on write filesystem, none of thismetadata is overwritten in place. Instead, all metadata is writtento a new location, all the way up to the uberblock. This is simplefor everything except the uberblock; you write the new version of the
The different ways that you can lose a ZFS pool
There are at least three different general ways that you can lose a ZFSpool.
The straightforward way that everyone knows about is for you to lose atop level vdev, ie to lose a non-redundant disk, or all of the disks ina mirror set, or enough disks in a raidzN (two disks for raidz1, threefor a raidz2, etc). Losing a chunk of striped or concatenated storage isessentially instant death for basically any RAID system and ZFS is noexception here.
(I
An important way to get ZFS metadata corruption
In yesterday's entry on how to lose ZFS pools , Iwrote:
The third way is to have corrupted metadata at the top of thepool. There are a number of ways that this can happen, but probablythe most common one is running into a ZFS bug that causes it to writeincorrect or bad data to disk [...]
I'm pretty sure I'm wrong about that and that there is a much morecommon way to get corrupt metadata: disk systems that lie to you
X and the misleading claim of 'mechanisms not policy'
One of the mantras of X has always been that it provides mechanisms,not policy; the policy is up to whatever you run on top of it. SoX does not dictate a specific look and feel, or even how windowsare managed, and boosters of X are quite proud of this. Various Xprograms have adopted some close variant of this mantra for their ownguiding principle; for example, I believe that a fair number of windowmanagers take this approach (especially fvwm-style window managers ). The
Fvwm as a window manager construction kit
I've mentioned in the past that I use fvwmas my window manager. However, that doesn't tell you as much as youmight think about what my environment looks like because fvwm is notso much a window manager as a window manager construction kit, in muchthe same way that exim is not a mailer but a mailer construction kit .
Historically (and currently) there have been (at least) two sorts ofwindow managers for X. The first sort is more or less fixed windowmanagers such
Email has two faces today
I've recently realized something about email. In the modern world,email has become at least two applications in one. Email has becomeboth an internal communication system and an external communicationsystem, where 'internal' and 'external' are not necessarily based onorganizational boundaries but are also a matter of a trusted circle ofregular correspondents.
(I'd argue that this split exists even if your job involves dealingwith the outside world. Email from your boss is still at least somewhatdifferent from email from customers
A realization about cache entry lifetime and validation
In the process of some recent thinking about caches , I had one of those obvious realizationsabout the relationship between cache entry lifetimes and how correct youneed to be with cache (in)validation.
Under many circumstances, there is an inverse relationship: the shorteryour entries are potentially valid for, the looser and less guaranteedcorrect you can be with validating or invalidating them. Conversely, thelonger the entries live the more careful you need to be with validation;the ultimate version of this is that entries never time out
Thinking about when not disabling iSCSI's InitialR2T matters
A commenter on a recent iSCSI entry askedme if disabling initial R2T had made anydifference. I can't answer the question because we haven't actuallydone any of my iSCSI tuning ideas yet, but in theprocess of saying that I wound up thinking about why I didn't expectdisabling initial R2T to make much of a difference for us.
Let's backtrack for a moment and ask what performance impact notdisabling initial R2T has. After the dust settles, requiring
Why xterm's cut and paste model is non-standard and limited
In yesterday's entry I made the offhandcomment that xterm 's cut and paste was non-standard. Since this causedsome confusion, it's time to amplify on that and, as a bonus, explainwhy xterm 's model only works in rather limited circumstances.
People came up with a standard model of cut, paste, and selections veryearly in the history of windowed GUIs (it may date to the Xerox PARCwork, I'm not sure), which goes something like this.
The importance of xterm for X Windows
In an earlier entry I said that you could make astrong case that X succeeded because its authors spent so much effort onmaking xterm a good terminal emulator. Today I feel like explainingthat.
First, let's be clear that xterm was (and is) a very good terminalprogram. It was fast and responsive, it worked well, it emulated almosteverything that a very popular real terminal did (which was importantbecause at least some things basically assumed that they were talking toa vt100