Partitionless for Performance

Geeky Gadget Gifts

I got a new disk for Christmas.

The disk in my primary workstation (a nice Lenovo ThinkPad) had begun to fail.  So my wife gave me a shiny new Seagate "Momentus" to replace the stock Hitachi.  I had fun copying the filesystems ... two dozen of them.  (Tedious, but nice to start fresh.)  "On a clear disk, you can seek forever."  (voice of Barbara Streisand)

I decided to go partitionless.
The old disk had four partitions:  two Windows partitions (came with the machine), a Linux boot partition, and the largest given over to LVM (logical volume manager) as a PV (physical volume, the backing store for Linux LVM).  That large partition was the sole PV in a VG (volume group) containing more than twenty filesystems.  The new disk is just one grand PV; no partition table.  Works.

It seems a little silly to have a partition table for just one partition.  Never the less, the concept of partitioning disks is so entrenched that we go that route by default.  Most uses do not require partitioning.

Using LVM in place of a partition table is really a whole different story.  If I had done things purely for the sake of this little blog post, I would have made one huge 750G filesystem (probably EXT4).  Been there; done that.  It works too.

Cheating ... a little

The title of this post is "Partitionless for Performance".  I'm stretching the story a bit.  The performance boost from discarding the partition table alone is negligible.  However, if your team gets used to the idea, then you may save on the human aspect of "performance": there would be one less thing to have to manage.  Put an arrow here.  This is the point.

Well ... there's also the point that we purists like getting rid of unused layers.

Running partitionless is kind of a big deal for me.  I do a lot of virtualization.  For virtual servers, unpartitioned "disks" make a lot of sense.  For example, servicing a filesystem from the "host" side is a whole lot easier when the (virtual) has no partition table to interfere.  If the virtual disk is represented by a file or a logical volume, you can mount it directly.  Voi-la!

So this is really more about manageability than about run-time performance.

The advantage seems obvious, but many people don't know it can be done. 

Disclosing Performance

The laptop is not virtual.
Going partitionless on the new disk was more to prove the point.  It works.
And when running partitionless, you could avoid LVM too.  (Except that PVs are identified by their UUID, so there may be less confusion w/r/t content.)

When it comes to operational performance, LVM can actually make things worse ... or better.  LVM is way more sophisticated than plain partitioning.  It naturally brings more internal complexity with it.  I'm looking for hard numbers, and I confess that I don't have them yet.  (And ultimately, if you can't measure it, ... you know how that goes.)

The wisdom of the community says that LVM adds little to the burden of disk I/O.  So until we get factual measurement, that's a smart place to start.

But then there is a case for a win, and it's a biggie.
LVM can add striping and/or redundancy.  Striping, if not offered by the physical backing storage, does improve performance.  (And redundancy helps a lot for recovery.)  There are measurements of the performance gains from striping.  (The value varies a lot based on your workload.)

The Road So Far

There is a bootstrapping issue.
Most bootstraps do not grok LVM.  They cannot pierce the LVM veil like they can pierce the partitioning veil.  I chose not to resolve this.  My solution is to boot from USB media.  (There were other reasons that removable boot media seemed like a good idea.  Maybe will talk about it in another post.)  It's been less than a week, and things are working very very well.

So the conclusion is this:
If you're running virtual, consider unpartitioned filesystems at offset zero.
When you're not running virtual, consider using LVM instead of a partition table.
(Perhaps not for your boot disk, but you get the idea.)