<html>
<head>
<title>Keeping filesystem images sparse</title>
</head>
<body>
<h2>Keeping filesystem images sparse</h2>
<p>
Filesystem images in local files can be used by many PC emulators and
virtual machines
(<a href="http://user-mode-linux.sourceforge.net/">user-mode Linux</a>,
<a href="http://fabrice.bellard.free.fr/qemu/">QEMU</a> and
<a href="http://wiki.xensource.com/xenwiki/">Xen</a>, to name but three).
Typically these filesystems are created as sparse files using
commands like:
<p>
<pre>
dd if=/dev/zero of=fs.image bs=1024 seek=2000000 count=0
/sbin/mke2fs fs.image
</pre>
where the enormous <code>seek</code> value causes <code>dd</code> to move
forward by 2GB before writing nothing at all. This results in the
creation of a sparse file which takes disk space only for blocks which are
actually used:
<p>
<pre>
$ ls -l fs.image
-rw-rw-r-- 1 rmy rmy 2048001024 Apr 18 19:10 fs.image
$ du -s fs.image
31692 fs.image
</pre>
As the filesystem is used, more and more of the non-existent blocks are
filled with data and the size of the file on disk grows. Sometimes it would
be nice to be able to reclaim unused blocks from a filesystem image. However,
deleting files from the image doesn't return the space to the
underlying filesystem: even free blocks in the image still consume space.
Reclaiming the space can be achieved in two stages:
<ul>
<li>Fill unused blocks with zeroes
<li>Make the file sparse again
</ul>
<p>
One traditional way to zero unused blocks is to create a file that fills
all the free space:
<p>
<pre>
dd if=/dev/zero of=junk
sync
rm junk
</pre>
<p>
The disadvantage of <code>dd</code> in this context is that it destroys
any sparseness that exists: free blocks that were originally represented
as holes in the image file are replaced with actual blocks containing
zeroes.
<p>
As an alternative approach, and as practice in mucking about with ext2
filesystems, I've written a utility which scans the free blocks in an
ext2 filesystem and fills any non-zero blocks with zeroes.
(The source, <a href="zerofree-1.0.1.tgz">zerofree-1.0.1.tgz</a>, is
available for download.) The <code>zerofree</code> utility is faster
than <code>dd</code>, especially when the filesystem is already partly sparse.
The filesystem to be processed should be unmounted or mounted read-only.
<p>
Better than either of these would be to have the guest kernel keep the free
blocks empty. My original inspiration was the
<a href="http://www.uwsg.iu.edu/hypermail/linux/kernel/0401.3/1058.html">
ext2fs privacy (i.e. secure deletion) patch</a> described in a Linux
kernel mailing list thread. I've also made use of a later patch for ext3
entitled
<a href="http://marc.theaimsgroup.com/?l=linux-fsdevel&m=113986429313502&w=2">Secure Deletion Functionality in ext3</a>
from the linux-fsdevel mailing list. (See also the authors' paper on
<a href="http://www.filesystems.org/project-sdfs.html">Secure Deletion File Systems</a>.)
I've modified the patches to make them more suitable for the present purpose.
<ul>
<li><a href="linux-2.6.25-zerofree2.patch">linux-2.6.25-zerofree2.patch</a> (for ext2 filesystems)</li>
<li><a href="linux-2.6.25-zerofree3.patch">linux-2.6.25-zerofree3.patch</a> (for ext3 filesystems)</li>
</ul>
When a filesystem is mounted with the <code>zerofree</code> option (added
by these patches) all the blocks freed when a file is deleted are filled
with zeroes.
Remember, this extra work will hurt disk performance.
Note that the ext3 patch doesn't support data journalling
mode, so deleted metadata isn't zeroed. It also hasn't been tested
as thoroughly as the patch for ext2.
<p>
However, the above techniques are only half the story: the empty free
blocks still consume space in the underlying filesystem, so something
must to be done to reclaim that space. One approach would be to
implement a system call, like the legendary
<a href="http://www.uwsg.iu.edu/hypermail/linux/kernel/0106.3/1180.html">
sys_punch</a>, which could be used to write a utility to make any
suitable file sparse.
<p>
An existing alternative is to use the sparse file handling capabilities
of the GNU <code>cp</code> command to take a copy of the filesystem image with
<code>cp --sparse=always</code> (though this does require the original
and sparse files to exist at the same time, which may be inconvenient).
<p>
As an alternative alternative I've written a utility which can make
any specified files on an ext2 filesystem
sparse, <a href="sparsify.c">sparsify.c</a>. This doesn't require any
additional disk space to work its magic, but it does require that the
filesystem containing the filesystem image is unmounted, which is just a
different sort of inconvenience.
<p>
(The usual disclaimers apply: this worked for me
when I tested it but it might destroy your data. Only use it on
disposable filesystems, or have a full backup available. <code>e2fsck</code>
is your friend.)
<p>
As an example, suppose we have an unmounted filesystem
image, <code>fs.image</code>, in the directory <code>/data</code>, which is the
root of the <code>/dev/hda2</code> filesystem. We can reclaim deleted
blocks and make it sparse like so:
<p>
<pre>
zerofree /data/fs.image
umount /data
sparsify /dev/hda2 /fs.image
mount /data
</pre>
<p>
<hr>
<address>
<a href="mailto:rmy@tigress.co.uk">Ron Yorston</a><br>
29th July 2008
</address>
</body>
</html>