Btrfs is a new file system for Linux, one that is still very much in development. Although I wouldn't exactly describe it as "experimental" any more, it is, as stated in the Wiki at kernel.org, "a fast-moving target".
It has also been said publicly that the basic format and structure of the filesystem should now be stable; it would only be changed in the future if some overriding reason or need is found.
The point of all this should be clear — it is still very early days, and it is not recommended to use btrfs in critical systems of any kind.
I leave it to the reader to decide how critical their systems are; for my own purposes, I will be using btrfs on several systems that I use as testbeds, some of which I carry with me and use for normal work on a daily basis, so it will get a "real" test, but I will not be using it on the primary systems that my partner and I use for home/work/business activities.
So, with that out of the way, now let's get to the point. I have no intention of trying to repeat or even paraphrase the information from their Wiki about the reasons behind Btrfs, the complete list of advantages it offers over other filesystems, or the disadvantages, limitations or preferred situations or scenarios for its use.
I will say that I became interested in Btrfs for the following reasons:
- It is obviously becoming increasingly important to the future of Linux systems, and I want to keep current with such developments
- It is possible to dynamically resize mounted filesystems
- filesystems can span physical volumes, with optional RAID support
- physical volumes can be added to and removed from mounted filesystems
- compression option
- snapshots (including read-only and read-write) and seeds
This is only a very short list, especially compared to the detailed list included in the Wiki mentioned above, but these are all issues that I have had to deal with, or suffered from not being able to deal with, over the years.
There have been a few other developments in file systems over the years which looked like they might address some or all of these issues (xfs and zfs come to mind), but for one reason or another (usually non-technical, unfortunately) they haven't become generally viable alternatives. I have been watching btrfs for some time, and had told myself that when it seemed stable enough and well enough integrated and supported in Linux, I would give it a try. As will be shown below, the latest openSuSE and Fedora releases seem to have reached that point.
So the first step is to get some kind of btrfs filesystem. There are two ways to do this — create one (duh), or convert one (huh? really? cool!). The simplest example would be creating a new btrfs filesystem within a specified disk partition, for example:
Of course, this is the "old school" CLI approach, and the same thing can be done using most of the modern GUI disk management utilities, such as gparted:
Alternatively, one can convert an existing ext3 or ext4 filesystem to btrfs.
Important! There are a variety of limitations and restrictions on using btrfs for the root (/) and/or boot (/boot) filesystems.
Do not go charging off and convert these kinds of critical filesystems to btrfs, because you will almost certainly be disappointed with the consequences. The kinds of things one might want to convert to btrfs are your home, work, data and other such additional filesystems.
Also, anyone doing this should make sure they have adequate backups of whatever they convert — not only because btrfs is still in development, but also because they might well make a mistake, or get surprised by something, and end up deleting, corrupting or otherwise losing the data in a converted filesystem.
It's possible to convert an existing ext3/ext4 filesystem to btrfs. The filesystem has to be unmounted, and should be checked (fsck) first. The conversion command is simple:
Replace the XX in the example above with the partition to convert. This will convert the filesystem to btrfs, and it will make a backup copy of the original partition which will be stored in a subvolume of the converted filesystem.
At this point I have a btrfs filesystem, either a newly-created emtpy one, or one which contains the data converted from one of your existing ext3/ext4 filesystems. I could go on from here and learn about things like subvolumes, snapshots, growing, shrinking and adding partitions and devices. But my interest is in creating complete btrfs-based systems, so I am going to press on with that. I will return to a discussion of most of those other features and capabilities in a subsequent post.
According to the btrfs Wiki, at least the following Linux distributions include support for btrfs filesystems: Arch, Debian, Fedora, Gentoo, openSuSE and Ubuntu.
I know that there are others by this time, including of course a lot of variations and derivatives of the above list, and of course there are commercial distributions including SUSE, Red Hat and Oracle. I happen to be right in the middle of new releases from openSuSE (13.1 just out) and Fedora (20 about to come out), so I decided to use them for testing.
When you talk about a distribution "including btrfs support", there are three very general levels possible:
- Include the btrfs-tools package. This will give you the ability to create, convert, examine and manipulate btrfs filesystems.
- Include support for btrfs in the operating system installer utility. This means that the root filesystem can be btrfs, and the installer takes responsibility for making sure that you can boot it somehow (see the next point)
- Include support for btrfs in the bootloader (grub, lilo or whatever). This means that your entire system can be btrfs all the way through, but it is not strictly necessary; as we have learned when other new filesystems have come along, you can keep a separate /boot partition of type ext4 (or less), and use that with non-btrfs compatible bootloaders while having everything else (including the root filesystem) btrfs.
openSuSE 13.1 is a btrfs through-and-through system, including boot capability, and creating a btrfs system is as easy as checking the appropriate box in the disk partitioning screen:
For simplicity here I have removed the separate /home partition. The window shows the actions which will be taken to create this layout, it is always a good idea to review this information before proceeding.
If for some reason I was deleting, overwriting or otherwise destroying an existing partition, it will be shown there in red. This looks like a pretty scary list of actions, especially compared to my normal ext4 selection, which produces one or two lines here, but on closer inspection it is pretty simple. It will create only one new partition (/dev/sda15), and then the next 11 lines are just subpartitions to set up the various parts of the root filesystem. The final two lines configure openSuSE to use the existing swap and EFI boot partitions. This is actually so simple, and so easy to do, that I was sceptical at first that it would work, but it really does, and very well.
Fedora 20 is a btrfs root with ext4 /boot configuration, and it requires a bit more manipulation to achieve it. After selecting the disk for installation, I get the Installation Options screen shown below. In this screen, change the Partition Scheme from the default LVM to BTRFS. If I were willing to accept the defaults for everything else (file system size and layout), I could just go ahead and let the installer run. I prefer to make some adjustments to the defaults — most importantly to use the existing swap and EFI boot partitions - so I also check the "I want to review/modify..." option on this screen.
Now I am in the Manual Partitioning screen. Here I have removed the swap area that anaconda wanted to create (don't worry, it will find the existing swap partition), and I have redirected the EFI boot to the existing partition as well. For our purposes the more relevant and interesting parts are that anaconda will create a btrfs filesystem (by default using all available space on the disk), and put both root and home in it, and it has created an ext4 /boot partition.
If I didn't want btrfs to use all of the free space on the disk, I could Modify and then set a fixed size for it. When I click Done, anaconda shows me the actions that it will take. Again, it is a good idea to review these to make sure it is not doing something unintended.
No surprises here — create an ext4 partition for boot and a btrfs partition for root, and further subpartition that for root and home. Let anaconda run through the installation, and everything completes normally.
Once the installation is completed (either or both of the above), I reboot to the installed system and what do I see? Not much, at least for the casual observer. It all looks, feels and works like your typical Linux system. It takes a bit of investigation to see the differences. For example, you can use the mount command, and mixed in with a bunch of other lines you will see this:
/dev/sda15 on / type btrfs (rw,realtime,space_cache)
Aha. Now that we know the name of the root partition, we can use the btrfs utility to examine it:
linux-6569:/home/jw # btrfs filesystem show /dev/sda15
Label: 'openSuSE_btrfs' uuid: 00e10875-995a-4bc6-a36b-7c823474cc85
Total devices 1 FS bytes used 4.76GiB
devid 1 size 16.00GiB used 7.04GiB path /dev/sda15
OK, that's a bit better... we can see that it is a btrfs filesystem, with a fixed size of 16GB and currently used 4.76GB. But that is still not all the information available, and I remember that the openSuSE installer actions said that it was going to create a bunch of subvolumes within the btrfs filesystem. So see those, we can use the btrfs subvolumes command:
btrfs subvolume list /home
ID 256 gen 40 top level 5 path boot/grub2/x86_64-efi
ID 258 gen 145 top level 5 path home
ID 259 gen 19 top level 5 path opt
ID 260 gen 20 top level 5 path srv
ID 261 gen 142 top level 5 path tmp
ID 262 gen 49 top level 5 path usr/local
ID 263 gen 29 top level 5 path var/crash
ID 264 gen 144 top level 5 path var/log
ID 265 gen 30 top level 5 path var/opt
ID 266 gen 145 top level 5 path var/spool
ID 267 gen 144 top level 5 path var/tmp
ID 272 gen 94 top level 5 path .snapshots
ID 273 gen 50 top level 5 path .snapshots/1/snapshot
ID 274 gen 51 top level 5 path .snapshots/2/snapshot
ID 275 gen 61 top level 5 path .snapshots/3/snapshot
ID 276 gen 62 top level 5 path .snapshots/4/snapshot
ID 278 gen 76 top level 5 path .snapshots/5/snapshot
ID 279 gen 80 top level 5 path .snapshots/6/snapshot
ID 280 gen 84 top level 5 path .snapshots/7/snapshot
ID 281 gen 93 top level 5 path .snapshots/8/snapshot
Ah, there they all are... and a few extras at the end, which appear to be automatic snapshots that have been made along the way.
So, I'm about ready to call it a day. So far I have been able to create (or convert from ext3 or ext4) a btrfs filesystem, and I have been able to install both openSuSE 13.1 and Fedora 20 with btrfs as the root filesystem. From here, in the next post, I will go on and look at some of the more interesting characteristics and capabilities of btrfs.