Interview: Chris Mason about Btrfs

Tux
I asked Chris Mason some questions about his new file system, and he kindly answered me. Chris outlined the current state of development of Btrfs as well as the future plans.

When Btrfs was officially announced I was very interested in the development because it was supposed to address several issues of today’s file systems. After a couple of early development releases I asked Chris if he would be willing to answer me some questions about Btrfs. He agreed but asked me to wait after the podcast of Oracle’s TechCast crew. This gave me the chance to only address topics not covered in the podcast and some days later I got the answers from Chris:

Q: Please introduce yourself to the readers.

I got started in the Linux kernel by adding journaling to ReiserFS v3, and I’ve been doing FS and kernel development since then. Today, work in Oracle’s Linux Kernel Engineering group, where we focus on mainline kernel development.

Q: Describe Btrf with your own words.

Btrfs is a new filesystem released under the GPL that is designed to scale to huge storage. Scaling doesn’t just mean being able to address that storage, but also deal with corrupt data and metadata. This means online filesystem checking tools and repair, and integrated checksumming to detect errors.

Q: What is the audience Btrfs is targeted at?

It is aimed at being a very general purpose filesystem. It should be very efficient both for large files and tiny files, and perform well under a variety of workloads.

Q: In which state is Btrfs at the moment?

Very early alpha state, with the disk format still not finalized.

Q: Which features does it offer now?

oss.oracle.com/projects/btrfs will be the best place to check development status. The core filesystem code is there, which includes snapshotting, subvolumes, checksumming (data and metadata), extents and some others. Many major features are still missing though, such as metadata mirroring and integrated device mapper support.

Q: Which features are planned for future releases in general?

Tuning and stability are my major concerns, but there’s quite a lot missing on the feature list. Xattrs and ACLs are not yet implemented, along with incremental backups, scalable locking, and a dozen or so other important bits.

Q: When do you expect the next large mile stone? What will it be about?

I plan on finalizing the disk format this year, and have it be something I’m willing to run on my home directory. I’m already using
Btrfs for my own mail spool, but my mail config live mirrors to a stable filesystem. I wouldn’t suggest other people use it for more than review and benchmarking.

Q: When do you expect a first version which can be tested by interested users?

Hopefully that will happen early in 2008. I only started on Btrfs in February of this year, so that would be a very rapid development cycle.

Q: When do you expect a first production-ready version? When do you expect the integration into the vanilla Linux kernel?

That will depend on how testing goes once the disk format is finalized, and on how many other developers I can attract.

Q: What is the best way to get in touch with the Btrfs development for interested developers, for interested users?

oss.oracle.com/projects/btrfs has status and mailing lists.

Q: What is the long term scope of your project in regard to Oracle’s OSS strategies and solutions?

Btrfs started as a personal project, but the more I worked on it, the more I became convinced it was a good way to solve some real problems we’re facing today. Today it fits into Oracle’s general strategy of improving Linux over the long term.

Q: Where do you see Btrfs in the OSS world in 5 years from now on?

I would hope to see it as the new default filesystem, but seeing it in the kernel with a large number of users would be wonderful.

Q: Several people might be interested what you think about ZFS, why you see a need for Btrfs “despite of ZFS” (some people think ZFS is the solution for everything for them).

Well, the short answer is that for Linux, there is no ZFS. I know about the FUSE port, but that isn’t a long term solution in terms of performance or enterprise workloads. ZFS has an impressive list of features (and clearly many happy users), but the real competition for Btrfs is other Linux filesystems.

Q: In a comment about your podcast a reader asked why not everyone would help ReiserFS. What is the difference between ReiserFS and Btrfs?

I worked on ReiserFS v3 for a number of years, and so I have a lot of respect for the Namesys developers. Adding the snapshotting, checksumming and other reliability features to ReiserFS v4 would have basically meant changing the disk format and rewriting big portions of the code. I would have also needed to fork the project into a GPL-only variant.

Q: In the end the file system has to be used by applications. Snapshots need tools which can handle them in an intelligent way – I think of versions of files and similar techniques. So is there any cooperation going on with GUI developers or environments like Gnome or KDE? Or do you plan to set this cooperation up at some point? Or is this something which has to be done by others because you need the time to bullet proof the file system?

It is definitely a complex problem, and I’m somewhat leaving it alone for now. Btrfs will have enough building blocks that we can work with application developers to highlight the snapshotting and incremental backup features. But, I’m definitely more focused on stability and performance right now.

I’m left to say Thank you, Chris Mason! for the time and the detailed answers. I’m looking forward to test Btrfs!

About these ads

3 thoughts on “Interview: Chris Mason about Btrfs

  1. “After a couple of early development releases I asked Chris if he would be willing to ask me some questions about Btrfs.”

    The author of the article wishes to be questioned on btrfs by the author of btrfs????

    That sentence should read: “After a couple of early development releases I asked Chris if he would be willing to answer some questions about Btrfs”.

Comments are closed.