Common threads

Advanced filesystem implementor's guide, Part 10

Deploying XFS


In this article, I'll show you how to get XFS up and running on your system. First, make sure that you're aware of and have explored the SGI XFS Project page (see Related topics later in this article). If you follow the download link, you'll find patches, tools, and even Red Hat XFS-enabled kernels.

But wait. While it is possible to install XFS using these pre-rolled, official releases, I don't recommend this approach. At the time this article was written, the most recent official release of XFS was 1.0.2, which was released way back in November 2001. A lot of improvements have been made to XFS since then, and in order to benefit from those improvements, it's best to use the up-to-date sources from the XFS CVS tree. Based on feedback from Gentoo Linux developers and users, those who have used XFS from CVS have had a much more positive XFS experience than those who have tried using the slightly outdated official releases.

Using CVS

If you've never used CVS before, you might be interested in my tutorial, CVS for the developer or amateur (see Related topics). If you'd rather just "wing it" and follow along, well, that's okay too. Just make sure that you have a CVS package of some kind installed on your system so that you can use the cvs command.

The CVS instructions I provide here can also be found on SGI's site (see Related topics). When you're done grabbing your sources via cvs, you'll have a new directory tree that contains up-to-date XFS-enabled kernel sources and the latest XFS tools. To grab the sources from XFS CVS, first set the CVSROOT environment variable to the repository from which you need to grab the sources. At the bash prompt, type:

$ export CVSROOT=''

Now, change directories to where you'd like the new XFS directory tree to be created, and type:

$ cvs login

When prompted for a password, type cvs. You're now logged in to the public CVS repository; to get the most recent XFS sources, type:

$ cvs -z3 checkout linux-2.4-xfs

The checkout process will begin. It may take a while, since the files you're grabbing include a complete Linux source tree. After a while, the cvs checkout command will complete and you'll have a new linux-2.4-xfs directory tree in your current working directory. For future reference, if you ever need to update your new source tree, simply enter the linux-2.4-xfs directory and type:

$ cvs -z3q update -dP

Using the tree

Two important directories are inside the new linux-2.4-xfs directory. The first is called linux and contains an XFS-enabled kernel source tree, and the second is called cmd and includes sources for the various XFS userspace programs. To use the kernel sources, you can either copy the linux directory to /usr/src or simply compile a new kernel in place.

Here's how to get this kernel up and running. Enter the linux directory and load Makefile into your favorite editor. At the top of the file, you'll see a few lines that look like this:


These lines tell the Makefile to build a kernel with the official name 2.4.17-xfs. Some prefer having a kernel without an -xfs in the official uname -a kernel name; if you're one of these people, then change the last line to read:


Now for kernel configuration. To enable XFS, type make menuconfig and head over to the File systems section. Scroll down a bit and you'll see the following option:

< > SGI XFS filesystem support

Enable it (compiling it directly into your kernel is recommended). Hit y, and the following three sub-options will appear:

[ ]   Enable XFS Realtime support  
[ ]   Enable XFS Quota 
< >   Enable XFS DMAPI

The "XFS Realtime" option will enable realtime subvolume support in XFS, which lets you configure storage areas that can provide more deterministic performance for realtime applications. The "XFS Quota" option will -- you guessed it -- enable support for associating disk usage limits with certain users and groups. The "XFS DMAPI" option, if selected, will enable a special API that is intended for use by storage management applications. Currently, no production Linux tools take advantage of DMAPI (this includes Sistina's LVM as well as the SGI XFS utilities themselves); however, some DMAPI-enabled applications are currently in development by SGI and IBM.

Once you've selected "SGI XFS filesystem support" and the rest of the kernel is configured the way you like it, you're ready to make dep && make bzImage && make modules && make modules_install, install your kernel, and reboot.

Installing the tools

Now that your XFS-enabled kernel is up and running, you can get the various XFS tools installed. One of the nice things about XFS is that it comes with a fairly comprehensive suite of support tools and utilities. Enter the linux-2.4-xfs/cmd directory and type the following shell script at the bash prompt as the "root" user:

# for x in attr acl xfsprogs dmapi xfsdump
cd $x
/configure --prefix=/usr
make install
cd ..

After you type the last done line, our ad hoc build script will begin executing, and all the various XFS tools will be installed. Now, you can finish up by installing a few developer-related files that weren't installed by the previous make install commands:

# for x in attr dmapi xfsprogs
cd $x
make install-dev
cd ..

Creating and mounting the filesystem

Once this final script completes, all the various XFS-related programs should be properly installed and ready for use. Now you're ready to create a test XFS filesystem tweaked for optimal performance.

But first, if you're creating an XFS filesystem on top of what was previously a ReiserFS filesystem, you'll need to perform a small trick. At the bash prompt, use the following command to "zero out" the beginning of the block device that was used to store the ReiserFS filesystem and is about to be initialized to contain your new XFS filesystem:

# dd if=/dev/zero of=/dev/hdc9

This step is necessary in order to wipe out any remaining ReiserFS metadata; otherwise, mount can get confused and accidentally mount your new XFS filesystem as a defective ReiserFS filesystem! You should only need to let dd run for about 10 seconds, after which you can abort the command with a control-C. At this point, the critical portions of the pre-existing ReiserFS metadata will be zeroed out, and mount's filesystem-type autodetection code won't get confused.

Now it's time to create a new filesystem. To do this, you could use mkfs.xfs as follows:

# mkfs.xfs /dev/hdc9

While the above command will work, there are a couple of options that you might want to mkfs.xfs to configure your new XFS filesystem for maximum performance.

The first such option is -l size=32m, which tells mkfs.xfs to configure your filesystem so that it has a hefty 32 MB metadata journal. This improves performance by making it less likely that your metadata journal will "fill up" during heavy filesystem usage.

The second option lets you enhance the performance of your new filesystem by telling mkfs.xfs to minimize the number of allocation groups that are created. Normally, mkfs.xfs chooses the number of allocation groups automatically, but from my experience it usually picks a number that is a bit too high for most general-purpose Linux workstations and servers. As you'll recall from my previous article, allocation groups let XFS perform multiple metadata operations in parallel. This comes in handy on high-end servers, but too many allocation groups do add a bit of overhead. So rather than let mkfs.xfs choose the number of allocation groups for your filesystem, specify a number by using the -d agcount=x option. Set x to a small number, something like 4, 6, or 8. You'll need at least one allocation group for every 4 GB of capacity in your target block device. Putting these two tweaks together, create an "optimized" XFS filesystem using the following command:

# mkfs.xfs -d agcount=4 -l size=32m /dev/hdc9

Now that your filesystem is created, you can mount it. When doing so, you'll use some performance-enhancing mount options to squeeze the last ounce of performance out of your new filesystem:

# mount /dev/hdc9 /mnt -o noatime,nodiratime,osyncisdsync

The first two mount options turn off atime updates, which are very rarely needed and serve little purpose other than to degrade filesystem performance. The osyncisdsync option tweaks XFS's sync/async behavior so that it is more in line with that of ext3. Thanks to our mkfs.xfs and mount tweaks, your new XFS filesystem will perform much better than it would have otherwise.

The goodies

One of the nice things about XFS is that it includes a lot of goodies. One of these goodies is some special functionality called "access control lists" or ACLs, and is now enabled on XFS filesystems by default. Access control lists let you define fine-grained permissions for files. For example, rather than simply being limited to defining "rwx" access for user, group, and all others, you can now add any number of additional users or groups and specify "rwx" permissions for them as well.

Full coverage of access control lists is beyond the scope of this article, but you can find a great introduction to ACLs on the bestbits site (see Related topics), particularly if you go to the "Why you may want Access Control Lists (ACLs)" page. Note that most of the in-depth technical information on that site is related to enabling ACL support under ext2 and ext3 (but no additional steps are needed to get ACLs working on XFS filesystems).

XFS includes another neat feature called "extended attributes." Extended attributes let you associate user-defined data with filesystem objects. For example, if you had a graphic called mygraphic.png, you could attach an attribute called "thumbnail" that contained a small version of the image. This data wouldn't be viewable by normal file IO operations but could be accessed by any program using a special extended attributes API. In a way, extended attributes resemble the "resource fork" that exists on MacOS systems.

Here's an example of how to interact with extended attributes using the attr command line executable. Let's say I wanted to add a description attribute to my home directory. I could type:

$ attr -s description -V "Home of Daniel Robbins" /home/drobbins
Attribute "description" set to a 22 byte value for /home/drobbins:
Home of Daniel Robbins

Then, to see a list of the attributes associated with /home/drobbins, I could type:

$ attr -l /home/drobbins
Attribute "description" has a 22 byte value for /home/drobbins/

And, to view the contents of the description attribute, I'd type:

$ attr -q -g description /home/drobbins/
Home of Daniel Robbins

Extended attributes are easy and fun to use. You can learn more about them by typing man attr. XFS includes a C API for interacting with extended attributes as well. If you're interested in working with a C++ IOStream interface to extended attributes, you may want to check out libferris on SourceForge (see Related topics).

Yes, extended attributes and ACLs are really fun, but beware -- most backup programs currently still ignore EA and ACL data. Notable exceptions are the xfsdump and xfsrestore commands included with the XFS distribution. If you're using any other backup program, be sure to do a bit of research before using extended attributes and ACLs all over the place.

I hope you've enjoyed this whirlwind introduction to the XFS filesystem. See you next article!

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Common threads: Advanced filesystem implementor's guide, Part 10