chunkfs - Man Page

chunkfs { -h | -V | <chunk size> <image file> <mount point> }

unchunkfs { -h | -V | <chunk dir> <mount point> }

ChunkFS allows you to mount an arbitrary file or block device as a directory tree of read-only files that each represent a chunk of user-specified size of the mounted file.

A possible use for this is space-efficient incremental backups of encrypted filesystem images using rsync's --link-dest option. That way you can create incremental backups from the ChunkFS-mounted image where any chunk that hasn't changed since the last backup will be a hard link to the corresponding chunk from the previous backup. In order to restore a revision, you simply have to concatenate all the chunks from the backup. Or you could use UnCunkFS to mount a ChunkFS tree (or a copy of one) as an image file.

<chunk size> is the size of the chunks into which <image file> is to be divided when mounted at <mount point>, specified in bytes. If the mounted file's size is not a multiple of the <chunk size>, the last file in the tree simply will be smaller than the chunk size.

In case of UnChunkFS, <chunk dir> is the directory that contains a ChunkFS tree (or a copy of one) that is to be mounted at <mount point>.

The chunk files of a ChunkFS are always at the eightth level of the mounted directory tree, if there are any (that is: if the image file is at least one byte in size). The concatenation of the path components from the root of the filesystem to a file gives you the hexadecimal representation of the number of the chunk that can be found in that respective file. This layout allows you to even incrementally backup files that have changed in size, as long as you do mount the ChunkFS with the same chunk size.

Note, however, that ChunkFS does not cope well with image files that change their size while they are mounted. It shouldn't crash, but you will not be able to access any newly-allocated space and you will immediately hit end of file, or maybe even get other errors, if you try to read from a chunk file for which there is no data in the image file anymore.

With UnChunkFS, you will always have exactly one file below the mount point, named image.

The permissions of the files within the ChunkFS are derived from the permissions of the image file. Owner and group are simply inherited. The mode of all objects is the same as that of the image file, except that any executable bits are cleared for files, while directories have their executable bits set for exactly those entities (owner, group, others) that also have read permission. In the same way, UnChunkFS derives ownership and permissions for its root directory and the image file from the root of the mounted ChunkFS tree. But see below for what all these permissions actually effect.

-h

Displays a short usage summary and all the options provided by the FUSE library.

-V

Prints the program version.

In addition to the options described above, there are quite a few options provided by the FUSE library. For most of those, I don't even know what they do and there doesn't seem to be any documentation. If you run chunkfs with the -h option, you will get a list of those options.

Note that, by default, the permissions described above are used for presentation only, not for actual permission checking. You might want to use -o default_permissions to change that, and maybe -o allow_other to actually allow others to access your ChunkFS mount.

        chunkfs 1048576 supersecretcryptoimage forbackup

This gives you 1 MiB chunks of supersecretcryptoimage mounted below forbackup.

        unchunkfs forbackup forrestore
        mount -o loop forrestore/image gimmebackmydata

When it's time for a restore.

        chunkfs 1 /dev/hda myharddiskinpieces

You always wanted to examine every byte on your hard disk individually, right?

If you want to use (Un)ChunkFS with block device snapshots, you might anticipate the problem that the snapshot of a journaling filesystem usually will need a log replay before it can be mounted--but you can't do any log replay on a read-only image like that provided by UnChunkFS, of course. As a possible solution, there is a writeoverlay.sh script included in this package's documentation directory that allows you to create from an arbitrary read-only block device a writable one by the means of the Linux device mapper's snapshot facility. Any writes to that device will be redirected to a temporary file. Make sure you read at the very least the comments within the script before you use it, as I wouldn't consider it production quality.

chunksync(1)

<http://chunkfs.florz.de/>

Copyright (C) 2007-2010  Florian Zumbiehl <florz@florz.de>

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

The man page unchunkfs(1) is an alias of chunkfs(1).