Snapshots and subvolumes
Snapshots and subvolumes are basically the same thing: they are separate "subvolume trees" within the "parent" file system. Strictly speaking, the file system we created with
mkfs.btrfs already contains a subvolume: When setting up a new Btrfs on a volume, the "default" subvolume is generated automatically and occupies the entire file system – while there are no other subvolumes or snapshots. In essence, snapshots are just subvolumes which (initially) point to the same directory and file tree as the original subvolume.
It only takes a split second to create a snapshot of a file system with the
btrfsctl -s name mount-point
command, for example in
btrfsctl -s /mnt/btrfs/snap /mnt/btrfs
The snapshot is subsequently available in the /mnt/btrfs/snap directory; this directory is created when the snapshot is taken.
Once a snapshot has been created, both the original file system and the snapshot point to the same data blocks: After taking the snapshot,
du -s (which simply adds up all the file sizes in a directory tree) displays twice as much occupied space as
df. When files in the original file system or in the snapshot are subsequently modified, the old data blocks are not deallocated, but instead kept for the respective other file system after the new data has been written – and it is only now that the occupied disk space actually increases. As a result, snapshots only require the same amount of space on disk as the data modified in the original file system or in the snapshot.
A subvolume can be created with the
btrfsctl -S subvol1 /mnt/btrfs
command. This generates the /mnt/btrfs/subvol1 directory used for accessing the subvolume.
Admins don't need to give existing snapshots or subvolumes any further attention: Btrfs memorises the structures even through a reboot. As the Linux standard tools are unaware of subvolumes within a file system, and the Btrfs developers haven't released any dedicated tools (yet), there is currently no way of establishing how full a subvolume or snapshot is, whether a Btrfs contains subvolumes and snapshots, or even whether a subdirectory contains a snapshot or subvolume. The
btrfs-debug-tree /dev/sda2|grep -A1 ROOT_REF
command at least returns the names of subvolumes and snapshots in a Btrfs at /dev/sda2.
We also didn't manage to delete a snapshot or subvolume: although it is possible to delete all the files in the respective directory, which does free up the occupied disk space, the directory itself stubbornly refuses to be removed. There is also no command for getting rid of a snapshot or subvolume in btrfsctl. This permanence even persists after a btrfsck run and remount.
In view of Btrfs's very early state of development, elaborate benchmarks with Postmark, Tiobench etc still seem slightly out of place. We therefore restricted our tests to timing the handling of large files and comparing the results with those recently achieved by Ext3 and Ext4 on the same test machine. Btrfs scored more than reasonably well:
Large file performance
Creating eight files of 1 GByte each
Deleting eight files of 1 GByte each
10,000 random read and write operations in 8 GBytes
1 Mount option: noatime; Single User Mode; file system newly mounted each time
2 file system newly mounted each time
Of course, this doesn't mean that Btrfs will leave Ext3 and Ext4 behind in any given situation – but it does show that the file system has a lot of potential not only in terms of scalability and management, but also in terms of performance.