Tip: Run test scripts in guestfish

In guestfish ≥ 1.3.5 you can run arbitrary test scripts using the debug backdoor (if it is enabled in your build, which it is in all Fedora builds). This is a good way to use the libguestfs appliance for your own tests or experiments. You can already do this using virt-rescue, but this gives you a way to script it.

For example, here we use the mke2fs “-T” option as an experiment:

$ guestfish
><fs> sparse /tmp/test.img 100M
><fs> run
><fs> part-disk /dev/sda mbr
><fs> debug-upload -<<EOF /tmp/script.sh 0755
#!/bin/sh -
/sbin/mke2fs -T news /dev/${sd}a1
EOF
><fs> debug sh "/tmp/script.sh"
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
25600 inodes, 25599 blocks
1279 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=29360128
1 block group
32768 blocks per group, 32768 fragments per group
25600 inodes per group
[...]

Note that two environment variables are made available to “debug sh” scripts:

• root is the path to where filesystems are mounted in the appliance, eg. “/sysroot”
• sd is the prefix for block devices, usually expanding to either “sd”, “hd” or “vd” depending on the block device driver and appliance kernel in use

None of this is portable or stable. We can change the “debug” interface at any time, and it might be disabled in particular builds on libguestfs. You should add commands that you need to the libguestfs API — it’s easy!

Filesystem metadata overhead

Which filesystems have the largest metadata overhead[1]? We can find out using guestfish sparse file support and a short shell script:

#!/bin/sh -

guestfish=fish/guestfish
testimg=/mnt/tmp/test/test.img
size=1G

for fstype in ext2 ext3 ext4 xfs ntfs msdos ; do
    $guestfish <<EOF
      sparse $testimg $size
      run
      sfdiskM /dev/sda ,
      mkfs $fstype /dev/sda1
EOF
    echo -n "$fstype: "
    du $testimg
done

The results:

Filesystem	Allocated kilobytes (out of 1G)	Overhead %
ext2	16948	1.6%
ext3 [2]	33352	3.2%
ext4 [2]	33288	3.2%
xfs	5132	0.5%
ntfs [3]	5748	0.5%
msdos & vfat	2076	0.2%
reiserfs [3]	32916	3.1%
btrfs [3]	4224	0.4%
hfs & hfsplus [3]	16432	1.6%
nilfs2 [3]	2060	0.2%
jfs [3]	4364	0.4%
gfs [3]	16612	1.6%
gfs2 [3,4]	132576	12%

Notes

[1] Yes, there are shortcomings in the methodology. What this really measures is how many blocks are written by the mkfs program. Even if you believe the figures, this only measures the initial overhead, but you can use the same technique to measure the overhead of storing (eg) lots of small files, or whatever is appropriate for your workload.
[2] Note the difference between ext2 and ext3/4 seems to be entirely down to the size of the journal, which is a kind of metadata overhead, but one that you can easily control.
[3] Needs three small patches to libguestfs to get these filesystems to work.
[4] This seems off the scale — needs further investigation.