A Btrfs field test and workshop

In the Hot Seat

Churning for Beginners

Creating a Btrfs filesystem doesn't take much more than unused disk space on a hard drive and the corresponding mkfs.btrfs tool, as you might expect. For later testing of the integrated volume management of Btrfs, this virtual Ubuntu instance has four extra devices of 32GB each (Figure 1). A filesystem with the label TEST is created with the

mkfs.btrfs -L TEST /dev/vdb

command.

Figure 1: A glance at the proc filesystem shows that four unpartitioned devices (/dev/vdb through /dev/vde) are available exclusively for Btrfs.

Creating a Filesystem

Creating a Btrfs filesystem is practically an instantaneous process because only a bit of metadata needs to be written, with no need for time-consuming inode table creation. The universal, all-purpose btrfs tool immediately gives you information about the freshly created Btrfs volume (Figure 2). This command-line program is a central tool for many Btrfs filesystem administrative activities. In this example, the Btrfs volume is identified by its label, but it can just as easily be addressed via the hard disk device name (/dev/vdb).

Figure 2: Creating a filesystem labeled TEST. The btrfs multifunctional tool provides additional information about the new Btrfs volume.

When called without switches, the command lists all the Btrfs filesystems known to the kernel. Note that mkfs.btrfs does not verify whether a Btrfs filesystem, let alone any other filesystem, LVM signature, or the like already exists on the hard disk. The newly created filesystem can now be mounted in the classical way:

mount /dev/vdb /mnt

A mount using the UUID or the filesystem label is, of course, also possible; you never know when the order or device name of the disk will change. Now, you can fill the fresh Btrfs with data. Using a local

rsync -a /usr /mnt

and dd, you can quickly populate the volume with a few gigabyte-sized files. Typing df -h /mnt then shows a corresponding utilization of 50%, or 16GB, as expected. However, internally, Btrfs actually uses more space to manage its growing metadata (Figure 3).

Figure 3: The df command only provides information about how much space the user data uses. Behind the scenes, Btrfs consumes much more disk space.

How Much Space Is Free?

The btrfs tool provides more detailed information on the real space usage of the filesystem. As long as the commands passed into btrfs are unique, they can be abbreviated.

The output from this command shows how much space is assigned and what percentage the metadata and payload can use. Also, the effective degree of use is visible to the user. The fi show command shows the total user data and the metadata space usage, but fi df gives more detailed insights into how Btrfs has allocated space to specific data types. The metadata is always stored redundantly by default to improve fault tolerance:

Data: total=16.01GB, used=15.40GB
System, DUP: total=8.00MB, used=4.00KB
Metadata, DUP: total=1.00GB, used=79.20MB

If Btrfs only has one device available when the filesystem is created, it automatically generates a duplicate of the metadata in a different location on the hard disk – shown here as DUP in the output from fi df. If several block devices are used to create the filesystem, then RAID 1 is used for the metadata and RAID 0 for the data. Different profiles can be selected for both metadata and payload data:

  • Single
  • RAID 0
  • RAID 1
  • RAID 10

For RAID 0 and RAID 1, you need at least two block devices; for RAID 10, at least four. The switches -mprofile for metadata and -dprofile for data give you granular control over how a new filesystem is created when you run mkfs.btrfs. The stripe size for RAID 0 and RAID 10 is fixed at 64KB and probably will not be changeable in the foreseeable future. Kernel 3.6 is expected to introduce the long-anticipated profiles for RAID 5 and RAID 6.

Buy this article as PDF

Download Article PDF now with Express Checkout
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Related content

comments powered by Disqus