Wandering Thoughts archives

A new piece of my environment: clearing the X selection

I've mentioned before that one of my little twitches is keeping my X selection empty so that I don't have any accidents with accidental pastes. For a long time I'd often do this by starting a new xterm, selecting a space, and then closing the xterm again. I was recently fiddling with my FVWM menus when it occurred to me that this was a crazy way of clearing the X selection and I should be able to do better.

So now I have a little script that clears the X selection and along with it a menu item that is called simply 'Clear' to run the script. Instead of going through a whole rigmarole with xterms I can just fidget with this by popping up the relevant menu and selecting it. I can't say that this exactly saves me time (this is a reflexive twitch), but it does make the whole thing less distracting because it's over faster and it makes me feel better about it. In retrospect I should have done this years ago.

(It also makes me happier. For all that I didn't think of the whole old rigmarole as any particular burden, I think it actually was and I just didn't notice it. There is probably a lesson to be learned here about other aspects of my environment but the problem is that these things are 'fish in water' issues; I'm probably not going to notice them until after I stumble into a fix.)

The script itself is:

#!/bin/sh
xsel -c
xcb -s 0 </dev/null

(This should probably also have 'xsel -c -b' to clear the clipboard selection too. So far I haven't needed that; programs like xterm ignore the clipboard if the primary selection and the cut buffer are empty.)

xsel is probably packaged for your Linux distribution. I had to compile xcb from source, but it's not exactly a big program.

(You need two programs because X has two separate selection systems. It's a long story.)

My views on various bits of disk drive technology today

trs80 asked (in a comment on this entry) about my views on various aspects of modern disk drives. This is actually an interesting subject for me because things are happening in the disk drive world that I hadn't been aware of until recently.

The big change that had passed me by entirely is the shift away from regular sized 3.5" hard drives to 2.5" (aka Small Form Factor) drives, what used to be 'laptop drives'. I'm used to thinking of these as things you wouldn't use outside of laptops but this is not at all the case any more. There are any number of 7200 RPM drives that will run happily in 24x7 setups, have long warranty periods, and apparently don't cost huge amounts of money over 3.5" drives of the same size. Using 2.5" drives is quite attractive in general because you get more drives into the same space and you can put SSDs in your drive bays without hassles (all SSDs that I've ever seen are 2.5" drives).

The bad news is that unfortunately we can't use them right now (although we'd like to). The largest 2.5" drives we've been able to spot are in the 1TB to 1.5TB range and this is just a bit too small for us. We're targeting 2TB drives in our hardware refresh as being a good balance between disk space and keeping our overall IOPS up (and also as being a decent size jump over our current set of drives).

This also means that we're targeting consumer level 7200 RPM SATA drives. I don't have any opinion on the relative merits of enterprise drives (whether 7200 RPM or faster) versus consumer drives because we've never had the money to buy anything but consumer drives. If money rained from the sky I think I'd still want to study the issue carefully because I'm far from convinced that 'enterprise' drives are worth the money, especially these days when you have much better options for high IO rates.

(After all a SSD will basically destroy even a 15k RPM hard drive. At that point you're down to 'higher reliability', if there is any.)

Money also dictates our limited use of SSDs. Today they are simply not price competitive for large storage; as trs80 mentioned they are something like 10x the per-GB cost of HDs (at least). They are excellent if you need the IO rates or if you have only modest storage needs (where the extra cost is small in absolute dollars), but this is not our space situation. We can only really afford to use SSDs as caches and write accelerators for regular (slow) hard drives. How much we'll be able to do this depends on how the budget comes out.

(We have already sprinkled SSDs over some important filesystems and we may do more of this, but we can't even vaguely afford to do it for everyone. And there is so far very little evidence that our users want and would be willing to pay for the drastically increased IO rates of an all-SSD ZFS pool.)

Funding and the size of hardware you want to buy

We need a new core router (among other things) and we'd also like to move towards 10GB Ethernet in our machine room. In general there are two broad approaches in this situation: you can buy a (small) router and then various separate switches or you can buy a single big core router+switch unit with many ports. There are various issues involving either choice and in the past we've gone back and forth between them in our network design. During discussions about this today I had an obvious in retrospect realization about our specific situation.

Our equipment funding is quite erratic and as result we buy stuff mostly in bursts. In this environment the problem with a single big unit is that significant updates to it are likely to be quite expensive and you probably simply won't have that money all in one lump at once. Or to put it another way, you may very well not be able to do a slow rolling upgrade with a single big unit. With separate small pieces of hardware you can do piece by piece replacements as you get much smaller chunks of money over time; first you update a switch here, then a switch there, then you replace the (modest) router, and so on.

(Big units like this are often modular but that modularity has limits. After a certain amount of time it's very likely that the vendor is going to stop developing new modules for your chassis; if you want the new whatever you have to upgrade chassis and probably a number of other things as well.)

This should really not have surprised me because it's exactly one of the drawbacks of having a single big server to do a lot of things instead of spreading the same things out over a bunch of smaller servers. Sooner or later you're going to have to replace the big server and that's going to be a lot of money at once. Upgrading the smaller servers may cost just as much (or more), but you can spread that cost out much more.

(In a sense this is a sad thing if the big server or the big core network box offer economies of scale or other benefits. But note that the overall organization may be getting important benefits from being able to spend the same amount of money in a steady but moderate stream instead of very bursty large chunks.)

Sidebar: the spares issue

Another issue with a crucial core router is spares and redundancy. With modular units you can stock a sufficient amount of spare modules instead of fully duplicating the unit, but chassises can break too and a spare one is probably not cheap. With a big unit (even a modular one) you're effectively paying for more spares and redundancy than you actually need.

How to accidentally reboot a server

This is a little war story.

To start out, determine that you need to add more memory to one of your login servers. This requires taking it down, which requires getting all of its users to log off first. Then go through the following steps:

1. Keep new logins off the system by changing your automated password management system to give all non-staff accounts a login shell that just prints out a 'this system is under maintenance, please use another one' and then quits.

   (Otherwise people will keep logging in to the server and you'll never, ever get a moment where there is no one on. Especially during working hours.)

2. Mail all of the current users to ask them to log off.

3. Get email from one user saying 'you can kill all of my processes on the machine'.

4. Do this in the obvious way. From an existing root session:

   /bin/su user
kill -1 -1

5. Have all of your (staff) sessions to the machine suddenly disconnect. Get a sinking feeling.

Perhaps you can spot the mistake already. The mistake is that the su to the user did not actually work. The user had a locked login shell, so all the su did was print a message and then dump me back into the root shell. Then I ran the 'kill -1 -1' as root and of course it SIGHUP'd all processes on the machine, effectively rebooting it.

(It didn't actually reboot and in fact enough stayed up that I could ssh back in, which surprised me a little bit.)

I should have used '/bin/su user -c "kill -1 -1"' or in fact one of the ways we keep around to do 'run command as user no matter what their shell is'. But I didn't take the time to do either of them.

(On the 'good' side, we got to immediately add more memory to that server.)