2015-11-30
My current dilemma: is it worth putting the root filesystem on a SSD
Due mostly to an extremely good deal at the end of last week, I'm getting a mirrored pair of 250 GB SSDs to add to my work machine. As 250 GB is not enough to hold all of the data that's currently on the machine, I'm going to have to be selective about what I put on the SSDs. Which leads to the question I'm currently considering; whether or not it's worth putting my machine's system filesystem on the SSDs, or whether I should use all of the space for a ZFS pool.
(As is the modern way, my system filesystem
has /, /usr, and /var all in a single large filesystem.)
The largest downside of putting my system filesystem on the SSDs is that it would consume at least 60 GB of the limited SSD space for good, and probably more so I had a safety margin for various sorts of space usage there (my current root filesystem is about 80 GB, but I'd likely offload some of the things that normally use space there). A secondary downside is that I would have to actively partition the SSDs instead of just giving them to ZFS as whole disks (even on Linux, ZFS is a bit happier to be handed whole disks). I'm using enough disk space for my own data that I'd like to move to the SSDs that losing 60-80 GB of space hurts at least a bit.
(In theory one might worry about /var/log and /var/log/journal
seeing constant write traffic. In practice write endurance doesn't
seem to be a big issue with SSDs these days, and these particular
ones have a good reputation.)
The largest downside of not putting my system filesystem on the
SSDs is of course that I don't get SSD performance for it. The big
question to me is how much this matters on my system. On the one
hand, certainly one of the things I do is to compile code, which
requires a bunch of programs and header files from /usr and so
on, and I would like this to be fast. On the other hand, my office
machine already has 32 GB of RAM so I would hope that the compiler,
the headers, and so on are all in the kernel's buffer cache before
too long, at which point the SSD speed shouldn't matter. On the
third hand, I don't have any actual numbers for how often I'm
currently reading things off disk for / as opposed to already
having them in memory. I can certainly believe that a modern system
loads random scattershot programs and shared libraries and so on
from / and /usr on a routine basis, all with relatively random
IO, and that this would be accelerated by an SSD.
If I was really determined enough, I suppose I would first try out a SSD root filesystem to see how much activity it saw while I did various activity on the system. If it was active, I'd keep it; if it wasn't, I'd move the root filesystem back to HDs and give the whole SSDs to ZFS. The problem with this approach is that it involves several shifts of the root filesystem, each of which is a disruptive pain in the rear (I probably want to boot off the SSDs if the root filesystem is there, for example). I'm not sure I'm that enthused.
(I'm not interested in trying to make root-on-ZFS work for me, and thus have the root filesystem sharing space flexibly with the rest of the ZFS pool.)
(What I should really do here is watch IO stats on my current software RAID mirror of the root filesystem to see how active it is at various times. If it's basically flatlined, well, I've got an answer. But it sure would be handy if someone had already investigated this (yes, sometimes I'm lazy).)
Sidebar: the caching alternative
In theory Linux now has several ways to add SSDs as caches of HD based filesystems; there's at least bcache and dm-cache. I've looked at these before and my reaction from then still mostly stands; each of them would require me to migrate my root filesystem in order to set them up. They both do have the advantage that I could use only a small amount of disk space on the SSDs and get a relatively significant benefit.
They also both have the disadvantage that the thought of trying to use either of them for my root filesystem and getting the result to be reliable in the face of problems gives me heartburn (for example, I don't know if Fedora's normal boot stuff supports either of them). I'm pretty sure that I'd be a pioneer in the effort, and I'd rather not go there. Running ZFS on Linux is daring enough for me.
A new piece of my environment: xcape, an X modifier key modifier
I was turned on to xcape by evaryont in a comment on my entry on my Backspace/Delete X key mapping shift. What xcape does is, well, let's quote from its own readme:
xcape allows you to use a modifier key as another key when pressed and released on its own.
A modifier key here is things like Shift, Control, and Alt (and CapsLock if you turn it into a modifier, such as making it another Control). The common use of xcape is by vi people to make one of those keys act as Escape when it's tapped, so they don't have to make the long stretch off to the top left of the keyboard for a key that they use all the time; instead they can tap something much closer.
(At the same time they don't lose the normal use of a valuable
modifier key the way they would if they completely turned one of
the modifier keys into Escape with, say, xmodmap.)
It's not clear how xcape works from the manpage or the readme. Before I started reading the code (it's short), I had concerns that it actually intercepted the modifier key and did weird things with it, which might interfere with other programs. This is not how it works. Instead, xcape passively listens to all keyboard events; when it sees a press and a release of the modifier key alone fly by within its time window, it injects a synthetic key-down and key-up event for your chosen additional key. No existing events are touched, only new ones added.
(Xcape is listed as Linux specific, although it might not be; it only seems to use the X 'record' and 'XTest' extensions, and I think they're generic. The record extension is used to monitor key events, the XTest extension to inject the new ones.)
What I'm using xcape for is a bit different from usual. Dmenu is a core part of my environment, and I have my window manager set to bring it up when I hit F5. F5 was in an easily reached location on my old keyboard, but on my new keyboard it's moved just enough so it's no longer a casual, rapid tap. So I'm using xcape to make tapping the CapsLock key (which I normally use as a Control key) also generate F5 and thereby bring up dmenu. The CapsLock key is of course in an extremely convenient and easily reached spot, which is great for this.
In general this works and achieves the goal of making bringing up dmenu be a fast, easy thing. The one drawback to reusing CapsLock is that I sometimes activate dmenu accidentally during normal typing; evidently I can plan to type a control character but then rapidly change my mind without thinking about it, which creates a CapsLock press and release close enough together to trigger xcape. If this turns out to be a long-term annoyance, I'll probably shift dmenu to being triggered off the much less used actual right Control key.
(This keyboard also has Windows keys, so I could go all the way to making the otherwise unused left Window key trigger dmenu, which wouldn't need xcape at all. But on the whole I like being able to call up dmenu so easily and casually, so I'm inclined to keep things the way I have them now.)
It's possible that someday I'll add an xcape mapping for Escape, but I'm extremely used to hitting Escape in its current location now (it's basically a reflex action at this point) and I don't really find it a problem. Still, I acknowledge that I may be missing out by not doing so and devoting the time to acclimatize to a new Escape location.
(I'd probably put Escape on the left Shift.)