ZFS Pool for Virtual Machines

Josip Medved Leave a comment

Running VirtualBox on ZFS pool intended for general use is not exactly the smoothest experience. Due to it’s disk access pattern, what works for all your data will not work for virtual machine disk access. Yes, you can play with record size and adding SLOG device but you can also go slightly different route. Add disk specifically for VirtualBox.

My testing has found that simple SSD with the following settings does wonders:

$ zpool create -o autoexpand=on -m /VirtualBox \
      -O compression=off -O recordsize=4K -O atime=off \
      -O utf8only=on -O normalization=formD -O casesensitivity=sensitive \
      VirtualBox /dev/diskid/DISK.eli

First of all, you don’t want compression. Not because data is not compressible but because compression can lead you to believe you have more space than you actually do. Even when you use fixed disk, you can run out of disk space just because some uncompressible data got written within VM. Due to copy-on-write architecture, you can still get into the trouble but exposure is greatly limited.

Ideally record size should match your expected load. In case of VirtualBox that’s 512 bytes. However, tracking 512 byte records takes so much metadata that 4K records are actually both more space efficient and perform better. Depending on your exact hardware you might find that going to 8K or even higher might hit the sweet spot. Testing is the only way to know for sure but 4K is a reasonable starting point.

All other options are just plumbing – of course you want UTF-8 and no access time tracking.

Now you can run VirtualBox without complicating your main data pool.

PS: This assumes that you have disks enumerated by diskid and fully encrypted.

PPS: I usually just spin up temporary virtual machines for testing and thus I don’t care much about them long term. If you plan to kick something up long-term, do consider mirrored ZFS.

Samba and Sync Writes

Josip Medved Leave a comment

Looking up information about ZFS SLOG, I always see the same advice: “SMB uses async writes and thus ZIL provices no benefits.” It’s sane advice as ZIL brings no benefit to asynchronous writes. Sane, but no longer true.

Samba 4.7.0 changed default value for strict sync parameter from no to yes. Practical consequence of this change is that ZIL SLOG will be useful even for CIFS shares and adding it will bring you some benefits.

Should you add ZIL SLOG is still question highly dependent on your actual clients and how your pool is structured. But answer is definitely not a straight “no.”

Farewell Mercurial

Josip Medved Leave a comment

My first love when it comes to distributed source control systems was Mercurial. It was powerful, simple, and it had excellent Windows client. Compared to Source Safe and CVS I was using before, it was a heaven.

While I first dabbled with local repositories, it wasn’t too long until I found BitBucket. As it was free for up to five users it seemed like a perfect home for many of my projects – both public and private. Yes, Git was getting popular at the same time but I preferred Mercurial. However, as more and more people started using Git, I switched.

Even when I switched to Git, I still continued keeping some projects on BitBucket – especially those where I collaborated with other users. It was simply much easier to get them used to TortoiseHg than to Git. For inexperienced user there was a real benefit in all restrictions Mercurial had by default.

Unfortunately, less than a year from now BitBucket will kill off Mercurial support.

I fully understand them. There was simply not enough Mercurial users out there to make it work. Even when I look at my own repositories, Mercurial is only a small fraction of my commits. However, I am still sad to see an old friend gone.

My guess I’ll convert most of my remaining repositories to Git. Considering how integrated Git got over the years with other tools, I am sure quite a few of shared repositories will go Git route too. For rest, I guess I’ll need to find another home.

Resetting Failed Upgrade on Supermicro

Josip Medved Leave a comment

While upgrading my Supermicro server’s IPMI firmware, I had Internet drop on me. It wasn’t a long drop but it was long enough to trigger dreadful “Service is not available during upgrade” error. No matter what I tried, the same error popped out.

Fortunately, if you’re running Linux and have your IPMI tools available, there is a solution. Just cold-boot BMC (small computer within your computer actually providing all those IPMI services) and wait until it’s back up:

$ unset HISTFILE
$ ipmitool -I lanplus -H 192.168.200.73 -U ADMIN -P ADMIN bmc reset cold

Once BMC reboots, it will forget all about interrupted firmware upgrade and allow you to continue on your merry way.

PS: If you are not sure if firmware update started before connection was interrupted, give it 10 minutes before trying this. This will be enough time for it to finish any real upgrade that might be in progress. You never want to interrupt firmware flashing.