diff --git a/.cvsignore b/.cvsignore deleted file mode 100644 index e69de29..0000000 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..021b6dd --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +zerofree-1.0.1.tgz diff --git a/Makefile b/Makefile deleted file mode 100644 index a2abd04..0000000 --- a/Makefile +++ /dev/null @@ -1,21 +0,0 @@ -# Makefile for source rpm: zerofree -# $Id$ -NAME := zerofree -SPECFILE = $(firstword $(wildcard *.spec)) - -define find-makefile-common -for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$/Makefile.common ] ; then cd $$d ; cvs -Q update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done -endef - -MAKEFILE_COMMON := $(shell $(find-makefile-common)) - -ifeq ($(MAKEFILE_COMMON),) -# attept a checkout -define checkout-makefile-common -test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo "common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to checkout the 'common' module." ; exit -1 ; } >&2 -endef - -MAKEFILE_COMMON := $(shell $(checkout-makefile-common)) -endif - -include $(MAKEFILE_COMMON) diff --git a/index.html b/index.html new file mode 100644 index 0000000..92e5b0d --- /dev/null +++ b/index.html @@ -0,0 +1,129 @@ + +
++Filesystem images in local files can be used by many PC emulators and +virtual machines +(user-mode Linux, +QEMU and +Xen, to name but three). +Typically these filesystems are created as sparse files using +commands like: +
+
+ dd if=/dev/zero of=fs.image bs=1024 seek=2000000 count=0 + /sbin/mke2fs fs.image ++where the enormous
seek value causes dd 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:
++
+ $ ls -l fs.image + -rw-rw-r-- 1 rmy rmy 2048001024 Apr 18 19:10 fs.image + $ du -s fs.image + 31692 fs.image ++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: +
+One traditional way to zero unused blocks is to create a file that fills +all the free space: +
+
+ dd if=/dev/zero of=junk + sync + rm junk ++
+The disadvantage of dd 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.
+
+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, zerofree-1.0.1.tgz, is
+available for download.) The zerofree utility is faster
+than dd, especially when the filesystem is already partly sparse.
+The filesystem to be processed should be unmounted or mounted read-only.
+
+Better than either of these would be to have the guest kernel keep the free +blocks empty. My original inspiration was the + +ext2fs privacy (i.e. secure deletion) patch described in a Linux +kernel mailing list thread. I've also made use of a later patch for ext3 +entitled +Secure Deletion Functionality in ext3 +from the linux-fsdevel mailing list. (See also the authors' paper on +Secure Deletion File Systems.) +I've modified the patches to make them more suitable for the present purpose. +
zerofree 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.
++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 + +sys_punch, which could be used to write a utility to make any +suitable file sparse. +
+An existing alternative is to use the sparse file handling capabilities
+of the GNU cp command to take a copy of the filesystem image with
+cp --sparse=always (though this does require the original
+and sparse files to exist at the same time, which may be inconvenient).
+
+As an alternative alternative I've written a utility which can make +any specified files on an ext2 filesystem +sparse, sparsify.c. 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. +
+(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. e2fsck
+is your friend.)
+
+As an example, suppose we have an unmounted filesystem
+image, fs.image, in the directory /data, which is the
+root of the /dev/hda2 filesystem. We can reclaim deleted
+blocks and make it sparse like so:
+
+
+ zerofree /data/fs.image + umount /data + sparsify /dev/hda2 /fs.image + mount /data ++
+