playing around with zfs ashift

For my next linux servers I’m exploring zfs as storage option. There is some stuff on zfs which you need to decide on zpool creation. This can’t be changed later without destroying your data.

The block size of the filesystem is one of these. In zfs this is named ashift. With this property you can balance the space which very small files take and the MB/s you get when reading very big files. The price you pay for that is disk space.

When you google around ashift=12 is recommamed today for hard disks, mainly because big hard disks have nowadays 4096 bytes sectors (ashift=12, 2^12) as default. But I also often read that ashift=13 is recommended for SSD’s.

I use zfs on SSD’s and normal hard drives. So ashift=13 for SSD’s?

Here some examples how the different ashift values influence your disk space.

I tested:

  • ashift 9, 512 bytes block size
  • ashift 12, 2048 bytes block size
  • ashift 13, 4096 bytes block size

Go here if you want to see this post in german.

sample data

linux source code

Here I use the linux source code as testing data. I use three copies of the source code.

Here as plain numbers.

tar xf /tmp/linux-4.0.tar.xz
cp -Ra linux-4.0/ linux-4.0.1
cp -Ra linux-4.0/ linux-4.0.2

# ashift 9
$ zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   742M   324G   741M  /tank

# ashift 12
$ zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  1.08G   324G  1.08G  /tank

# ashirt 13
$ zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  1.54G   323G  1.54G  /tank

With a lot of small file the space savings you get with ashift=9 are really big. You need twice as much space with ashift=13 instead of ashift=9.

a raw image file

Here I use a qemu raw image file.

Here as numbers.

# ashift 9
$ zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  2.82G   322G  2.82G  /tank

# ashift 12
zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  2.88G   322G  2.88G  /tank

# ashift 13
zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  2.94G   322G  2.94G  /tank

sample production data

This testing data consists of some django project data files, some typo3 project files and linux binaries.

# ashift 9
root@nara /tank # zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  5.28G   320G  5.28G  /tank

# ashift 12
zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  5.67G   319G  5.67G  /tank

# ashift 13
zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  6.13G   319G  6.13G  /tank

conclusion

I will use ashift=12 for SSD’s. For the SSD’s capacity I use, the space price to pay for ashift=13 is too high for me.

latest posts


2016 Macbook Pro rumors and predictions

This are all speculations, feeded by rumors and the latest PC laptops. case Apple always said the 12” Macbook is the “future of the notebook”. So it’s clear that the new Pro`s will look like bigger brothers of the 12”. The thing I like the most of the 12” is the color! Space grey on a Macbook looks awesome! It’s darker than the normal aluminum unibody. They should just add more than one USB-C port… So I hope the new pro will be also available in space grey and perhaps in pink, sorry rose gold :-).


zfs as local vm storage for vmware fusion on osx

I first used boot2docker as docker platform for Mac OS X. With Boot2docker it’s hard to customize stuff, because it’s not build for that purpose. Once I tried to put a desktop app into a docker container with 3D hardware support. The 3D performence was really bad… VirtualBox isn’t the best virtualization platform for this. When using boot2docker with Virtualbox I always thought this should/could perform a bit faster. See also my entry about file sharing in docker.