« previous 1 2 3

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.

Every Btrfs contains a default 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.

Performance

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:

¹ Mount option: noatime; Single User Mode; file system newly mounted each time
² 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.

(odi)

« previous 1 2 3