Wandering Thoughts archives


The feature (or features) I really want added to xterm

I recently mentioned that there were only a few features that could attract me away from xterm. Since a commentator asked about them, today I'm going to try to talk about them.

The big feature that I would like is for widening and narrowing the terminal window to properly reflow text. In other words, if I have lines that wrapped around and I widen the terminal window I want the lines to no longer wrap around. Today if you do that you just get a big blank space on the right. Similarly if I narrow a window I don't want the lines truncated, I want them re-wrapped.

(Mac OS X terminal windows do this. I have envied them that ever since I saw it in action many years ago.)

There are technical limitations and caveats about this but it's perfectly possible to do it in many common situations (ones where the output has been simply printed to the screen instead of placed with cursor addressing). Xterm actually goes part of the way to this today in that its line selection for copy-and-paste sometimes recognizes that a logical line spans more than the physical on-screen line.

The other interesting feature is signposted by gnome-terminal doing a much more restricted version of it: g-t will recognize URLs, underline them if you hover the mouse over them, and then give you a context sensitive popup menu that lets you do things with them. I would like a generalized version of this where you can provide something like regular expressions to match and context menu entries to add for each match.

There are probably more exotic things you could add to a terminal emulator if you wanted to; for instance, there's no reason why a terminal emulator couldn't directly render pictures if asked to. I can't say I actively want such features, though, partly because I'm not sure that we have a good idea of how to use them in a Unix command line environment.

(Also, I'm not interested in giving up what I consider xterm's core features for me. Trying to list those is something for another entry.)

PS: it's likely that there are other features that would pull me away from xterm that I just haven't had the vision to imagine. I try to always remember that the really great features tend to be the ones that you didn't even realize that you wanted before you heard about them.

unix/XTermWants written at 22:45:09; Add Comment

Multi-mount protection and SAN failover

Suppose that you have some machines, some shared disks, and a filesystem that has what gets called multi-mount protection, where it tries to prevent being mounted on two different machines at the same time. Do you have enough to do reliable SAN failover in the face of a crashed machine? Unfortunately the answer is no.

The first problem is that common implementations of multi-mount protection are not necessarily fully reliable. While it is possible to do reliable locking with only read and write operations to a shared disk (see eg Dekker's or Peterson's algorithm), many MMP implementations do not go to this extent; instead they rely on statistical properties, such as that a check block will get written every so often by the server that owns the filesystem. This usually works but cannot be absolutely guaranteed to do so in the face of a machine that is in an unknown but broken state.

(At the simplest level the check block might be written by a separate 'check block writer' process that has gotten stuck somehow.)

The larger problem is that multimount protection is essentially solving the wrong problem for failover. For forced failover, system A legitimately owned the filesystem when it was healthy and active but is now in some unknown but unhealthy state. Since it is in an unknown state, it has not properly released its ownership and you cannot count on it to be inactive. You want to forcefully take ownership of the filesystem away from system A and make it so that system A will not write anything more to the filesystem, and you must do this without system A's cooperation (because it may not cooperate, since it is in a bad state).

At best multi-mount protection will tell you that system A does not seem to have recently written anything that MMP checks. It cannot assure you that system A will not do any writes in the future. To do this you must somehow forcefully fence system A away from filesystem writes, either with storage-level features or simply by a remote power off of system A.

You can get away with active, check-based MMP for SAN failover only if you trust things to not go too badly wrong, so that the check saying that system A is inactive is sufficient to guarantee that it actually is and that it will stay that way.

Sidebar: two levels of multi-mount protection

The basic level of multi-mount protection is simply an 'is active' marker of some sort in the filesystem; a system sets the marker when it mounts the filesystem and unsets it when the filesystem is unmounted. This sort of MMP doesn't help you at all in failover because system A is unlikely to have actually released the filesystem before it stopped working right.

The advanced level of MMP is something in the filesystem that is actively updated on a frequent basis. If you passively watch the filesystem and there are no updates to the marker over a sufficiently long time, you can conclude that the theoretical owner either doesn't exist any more or at least is not working right.

tech/MultimountAndSANFailover written at 00:01:52; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.