Planning out a disk shuffle for my office workstation

April 14, 2017

As I mentioned yesterday, my office workstation lost one of its remaining HDs the other day. This HD is one side of a pair of 1 TB drives that's used for various mirrored partitions, so I haven't lost anything (unless the other side also fails before Monday, so let's hope not), but now I need to replace it with one of the ready spares I have sitting around for exactly this eventuality.

The obvious way to replace the failed disk is to do literally that; put in the new disk, partition it up to basically match the existing setup, and attach appropriate partitions to software RAID devices and my ZFS pool. That would certainly work, but it's not necessarily the right answer because my office workstation's current disk setup has mutated over time and the actual current setup of much of it is not what I would build from scratch.

Specifically, right now I have five drives with the following odd split up:

  • two paired SSDs, used for / and a SSD ZFS pool where my home directory and other important things live. (That my home directory and so on is on the SSDs is one reason I am not too worried about the current disk failure.)

  • two paired 1 TB HDs that used to be my only two drives. Because of that they still have partitions for my old HD-based root filesystem (in two copies), the /boot partition I just recently migrated into the SSD /, and finally my HD-based ZFS pool, which used to hold everything but now mostly holds less important data. Oh, and it turns out they also have my swap partition.

  • One 500 GB HD that I used as overflow for unimportant virtual machines, back in the days when I thought I needed to conserve space on the mirrored 1 TB HDs (in fact it may date from the days when these were actually 750 GB HDs).

My replacements for the 1 TB drives are 1.5 TB, so this already gives me a space expansion, and there's now any number of things on those two 1 TB drives I don't need any more, and also one thing I would like to have. So my current plan is to replace both 1 TB drives (the dead and the still alive one) and set up the space on the new pair of 1.5 TB drives as follows:

  • a small 1 GB swap partition, because it still seems like a good idea to give the Linux kernel some swap space to make it happy.
  • a 200 GB or so ext4 partition, which will be used for an assortment of things that aren't important enough to go in the SSD / but that I don't want to have in ZFS, partly because they're things I may need to get back access to my ZFS pools if package upgrades go wrong.

  • a 100 GB backup / partition. As is my current habit, before major events like Fedora upgrades I'll copy the SSD / to here so that I can kludge together a reversion to a good environment if something goes badly wrong.

  • all the remaining space goes to my HD-based ZFS pool, which should expand the space a decent amount.

(All partitions and ZFS and so on will be mirrored between the two drives.)

Given the likely space expansion in my HD-based ZFS pool, I think I'll also get rid of that overflow 500 GB HD by folding its 120 GB or so of actual space usage into the main HD-based ZFS pool. It was always sort of a hack and a bit awkward (on top of having no redundancy). Plus this will simplify everything, and I can always put the drive (or a bigger replacement drive) back in and redo this if I turn out to actually need a bunch more space for virtual machines.

In a way, I'm grateful that my 1 TB HD finally died and also that it happened under the circumstances it did, where I couldn't immediately rush into replacing it in the most obvious way possible and had forced time to sit back and think about whether the obvious path was the right one. I'm probably going to wind up with a nicer, more sensibly set up system as a result of this disk failure, and I probably never would have done this rearrangement without being pushed.

Comments on this page:

Do you have any interest in using part of the SSDs as L2ARC and / or ZIL?

Why not have the 100 GB backup be part of the HD ZFS pool?

By cks at 2017-04-15 00:23:21:

I already have a SSD ZFS pool for things I want to be fast, so I have little interest in stealing space from it to accelerate the lower-priority HD ZFS pool. Also, my earlier experience when I tried a (smallish) L2ARC on my HD ZFS pool when it was my primary pool was that the L2ARC didn't seem to speed things up much as far as I could tell.

The 100 GB backup root filesystem will be ext4 for the same reason that the real root filesystem is, namely that I have no interest in wading into the swamps of booting from ZFS. It is definitely intended that the backup root filesystem is directly bootable.

Have you seen the swapspace daemon? It creates and enables swap files on demand. Since swap is something you don't normally need, and SSDs are so fast, this strikes me as a great idea. I only just discovered it, but it's actually been around for a few years now.

Written on 14 April 2017.
« Sometimes laziness doesn't pay off
Migrating a separate /boot filesystem into the root filesystem »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Apr 14 22:53:11 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.