Name
Chris Mason
What role do you play in the community and/or what subsystem(s) do you work on?
I maintain the Btrfs filesystem and most of my work is inside the filesystems or other code in the IO paths.
Where do you get your paycheck?
What part of the world do you live in? Why there?
I live in Rochester NY. It’s where I went to college, and working on Linux meant that I never really had to move.
What are your favorite productivity tools for software development? What do you run on your desktop?
I use Arch Linux, mostly because the rolling update model is perfect for working against mainline. I use awesome for a window manager instead of any desktop environment. It’s a slick way to manage tons of windows.
My development tools are pretty basic, just vi and make. For navigating kernel code, I haven’t found anything better than cscope, but I keep hoping someone will integrate a live updating cscope style database into vi.
I’m using mutt for email, but I’ve tried all the gui programs at one time or another. They all have advantages, but the mutt-kz integration of notmuch is turning into a really nice way to index and work with email.
Git is a big part of kernel productivity, and you can’t understate how much git and the kernel workflow have been designed around each other. Every once and while, I end up coaching someone new to git and I realize again how complex all the moving pieces are.
For filesystem analysis, I wrote a tool called seekwatcher. It uses traces from blktrace to visualize what is happening on the disk, making it much easier to track down performance problems.
I recently reimplemented things in C instead of python and made a new tool called iowatcher, where I hope to add all kinds of features to watch what happens on flash devices.
How did you get involved in Linux kernel development?
It wasn’t kernel development, but in 1994 I started helping with the driver for an unsupported graphics card. It was great to get my hardware working, and I still have the distro CDs SUSE sent out back then to reward contributors.
A few years later I was a systems administrator, and I wanted to use Linux in our data center. At the time, Linux didn’t have a journaled filesystem and I couldn’t use Linux in production without one. I’d never worked on storage or the kernel before, so it was a little rough while I figured everything out.
But it was one of those features that everyone wanted, and I had a lot of encouragement and help along the way. Soon after that, I was working full time on the kernel.
What keeps you interested in it?
I’m able to interact directly with the users, which means I get instant feedback on new features and fixes. Going to conferences, I always meet new people using or working on Linux. It’s a great source of new ideas and motivation to keep improving things.
Linux is used in so many different ways that it really is impossible to be bored.
What’s the most amused you’ve ever been by the collaborative development process (flame war, silly code submission, amazing accomplishment)?
The flame wars must seem crazy from the outside, but sometimes they are an important part of fixing things. After a long argument about how easily you could trigger corruptions during power failures, I sat down and made a test. The results surprised many of us, and I still run the same test years later. I probably wouldn’t have spent the time on the test if not for the extra motivation of winning the argument.
My favorite is definitely the O_PONIES flame war. Someone even made a t-shirt in honor of that one. I’m sure I couldn’t do it justice describing it here, but it is a great example of how the compromises we make as developers can create impossible expectations later on.
What’s your advice for developers who want to get involved?
My first suggestion is to pick a project you enjoy using. The kernel has a steep learning curve, and it can be difficult to work your way into a development group. If you enjoy what you’re doing, you are much more likely to stick with it.
After that, fixing bugs is the fastest way to get to know the code. Pick something that you can trigger reliably, and it’ll be much easier to track down. Then do it over and over again until you know the code well enough to review patches from others. By then you’ll know the community well and you can branch out into almost anything.
What do you listen to when you code?
Usually I like the room quiet.
What mailing list or IRC channel will people find you hanging out at? What conference(s)?
There is #btrfs on freenode. For conferences, the Linux Filesystem, Storage and MM Summit each spring is always full of interesting topics. The Linux Foundation consistently does a great job on all of its conferences, and I try to attend them whenever they fit in my schedule.
