Currently at:
If you have any comments or suggestions just let me know:
XFS is a journalling filesystem developed by SGI and used in SGI's IRIX operating system. It is now also available under GPL for linux. It is extremely scalable, using btrees extensively to support large and/or sparse files, and extremely large directories. The journalling capability means no more waiting for fsck's or worrying about meta-data corruption.
Just point your web-browser to:
The best way to do this is to checkout the SGI XFS kernel from their CVS tree. How to do this is described at
After that you have two subtrees of importance: linux and cmd. The firsts one - linux - is a normal linux kernel source tree containing the XFS code. It is updated to the latest available linux kernel from time to time but it may be a bit (not much) behind. Just build your kernel the way you are used to do it and don't forget to enable XFS and pagebuf under filesystems. You also need to enable the ask for experimental features option in the "Code maturity level options" menu. The other tree - cmd - contains all the tools you need - most important: mkfs.xfs and xfs_repair - just go to the xfs subdirectory in cmd and type make (maybe followed by make install to install the binaries). The cmd tree has been restructured a bit at the beginning of 2001: now you have to go into the various subdirs (xfsprogs, attr, acl, xfsdump, dmapi) and run the make or the below described Makepkgs script there. One thing which is also important to note is that you need to have the e2fs-devel package installed in order to build the cmd tools - because they require the uuid stuff in them. You may also build src and binary rpms by running:
./Makepkgs verbose
in the cmd/xfs or cmd/[xfsprogs, attr, ...] directory. The tools also have man-pages which you may consult for interesting options.
There exists also another way to get an XFS ready kernel - you may get kernel patches relative to a official kernel from:
and apply then to the kernel sources the patch is for. This is a good way for all the people who don't want to use CVS or do not have the bandwidth to checkout the whole kernel tree.
A third way to get a XFS ready system and kernel is to use the prepared rpm's and experimental redhat install ISO images from SGI you may find also in the download area.
Just reboot the new build kernel and create a filesytem on an empty partition
mkfs -t xfs /dev/foo
where /dev/foo is the the partition you want to use (you may have to use the -f option of mkfs -t xfs (which calls mkfs.xfs from the cmd directory which you must have installed) if this partition already contains an old filesystem which you want to overwrite). Now you can mount the filesystem using:
mount -t xfs /dev/foo /somewhere
It is quite useable now but I would not recommend it for production use right now - but I think it will be there quite soon. I used it here in a test scenario for a 50 people squid and a ~20 mb/day newsfeed with 30 simulated users on an XFS only machine for quite some time and had no problems so far. Also SGI is doing quite a lot of stress tests with it (see the stress subdir of the cmd tree). In the last weeks and months more and more people are evaluating XFS in production-like environments with mostly good results.
The current XFS tree seems to work just fine on ppc now (aside from some trivial compile fixes). There is also work underway to get it to that state on the alpha and the sparc64 too which looks very promising. I think it should nearly run on those platforms right now (if someone is actually testing it there please let me know). All in all it looks like XFS will be running across a lot of platforms fine soon. Also an important note is that XFS is inherently platform independent in the on disk layout - so it should be possible to move a XFS disk from one linux platform to another out of the box.
If you are interested in this you may have a look at
Especially the ppc subdir there contains mostly quite up to date merged XFS and ppc trees which should work on ppc machines quite fine.
User quotas are supported, group/project quotas are work-in-progress.
To use quotas with XFS, you need to enable linux quota support, and XFS quota support when you configure your kernel. You also need to specify quota support when you mount. A patched version of the linux quota tools which supports XFS is in the cmd/quota directory of the XFS distribution. Hopefully XFS will be supported in the standard quota tools soon.
xfsdump and xfsrestore are now in the CVS tree. The tape format is the same as for xfsdump and xfsrestore on IRIX and dump tapes should be interchangable between systems.
The tape format is not the same as the classic Unix dump but should work fine with tools like Amanda. Dumps produced with standard other dump programs should be able to be restored onto an XFS filesystem using the coresponding restore program.
Yes
No - so far there is no direct support in GRUB to boot from an XFS filesystem but you may still boot an mostly XFS system with a small ext2 /boot partition with all the GRUB stuff on it using GRUB. Btw. writing XFS support for GRUB would be a good way to learn more about XFS if anyone is interested :-).
Yes you can but you need to use a patch for LVM because the XFS kernel contains stephen tweedies sard patches which change the format of /proc/partitions. Also for using XFS on LVM you should not enable the kiobuf option in the kernel XFS compile options. You may get a patch (created by William L Jones) to start from at
See the head of it for details and a list of contributors. With the current lvm 0.9.1 betas it is reported to work now out of the box, but there is still no kiobuff support for lvm and md devices.
Yes. If you are using a 2.4.2 based XFS kernel you need to apply Jens Axboes loop-xfs-7c fix for it to work (the fix is for a problem in 2.4.2 and has nothing really to do with XFS). You may get this patch from
Yes. A document describing how to convert your system to XFS is currently being worked on. The current state of this document you may find at
You might also have a look at my little stand-alone environment for converting and maintaining a root XFS filesystem at
Linux native filesystem (83).
If you get something like:
mount: /dev/hda5 has wrong major or minor number
you either don't have XFS compiled into the kernel (or you forgot to load the modules) or you did not use the "-t xfs" option on mount or the "xfs" option in /etc/fstab.
It seems to work with a special patch from Russel Cattelan which will be incorporated into the main tree soon. Also keep in mind - if you want to try it - also the md driver will definitely not work with the kiobuf option enabled.
Yes - hardware RAID is like a normal disk to XFS (like to any other filesystem) and this should not be a problem.
Yes. To get good performance make shure to use an XFS tree from after mid-march 2001. There were some important fixes for useable NFS-performance. However there may be some remaining issues under heavy load which are tested out right now.
An XFS filesystem may be enlarged within a partition using xfs_growfs. Back up your filesystem before using this tool.
Yes. The on-disk format of XFS is the same on IRIX and Linux. Obviously, you should back-up your data before trying to move it between systems. Filesystems must be "clean" when moved (ie unmounted correctly).
The only real caveat here is that at the moment XFS on linux only supports filesystems where the disk block size equals the page size. Support for other block sizes available on IRIX is work-in-progress.
There are some papers available on the SGI XFS project page (mentioned above) and I have set up an LXR indexed version of the SGI XFS CVS tree at:
which might help to find an easy and good way through the sources. I plan to keep this tree automatically updated to the current SGI XFS CVS version on a daily basis within the next days. If anyone has pointers to other XFS related docs - just send me a mail (address - see above).
Recompile your kernel with gcc 2.91.66 instead of gcc 2.95 this should fix your problem. On RedHat 7.x systems you get egcs via kgcc. See the comments in the top level Makefile of the kernel for more information about this.
Yes. So far there were some problems reported with kernels built with gcc 2.95 which were solved by compiling it with egcs 2.91.66 (or kgcc on RedHat 7.x systems). So for now please use version gcc 2.91.66 (aka egcs 1.1.2) to build your XFS kernel. If you are using a debian or SuSE based system this means that you may have to find and install this egcs version. Please note that the problems with gcc 2.95 seem to be restriced to the i386 platform - on the ppc it works just fine with 2.95 for instance.
Some of them are other interesting tools like: db - xfs_db is a xfs filesystem debugger (working) , copy - xfs_copy is tool for effectively copying one filesystem to another device (not yet ported), fsr - xfs_fsr is a defragmenter for xfs (working), repair - xfs_repair is the consistency checker for an xfs filesystem (working). As already mentioned earlier: the cmd structure has changed a bit at the beginning of 2001 - now it all looks a bit clearer i think (modeled a bit after the ext2 tools structure). The only two other subdirs are: quota - a quota-tools tree with the XFS additions in it and xfstests - the SGI XFS stress test suite.
This is because there is a syscall conflict which results in this problem. Please use the latest XFS code from the cvs tree which has this fixed. Eventually the beta will be rerolled for that.
Don't run those commands on a mounted filesystem - in this case it is normal that you see inconsistencies. Never run xfs_repair on a mounted filesystem without the "-n" switch at all. If you ran the commands on an unmounted filesystem then there seems to be something wrong with the filesystem.
First dbench: this is a very metadata intensive benchmark which might be a little limited by the default log size. You will getter better results by creating the filesystems with
mkfs -t xfs -l size=32768b -f /dev/device
This creates a bigger logspace. Also it is a good idea to mount meta-data intensive filesystems with
mount -t xfs -o logbufs=8,logbsize=32768 /dev/device /mountpoint
Note that in some earlier versions you may only use 4 logbufs as a maximum. Also since mid-march there are some changes in the tree which improve the overall dbench performance a bit. Have a look for the xfs.txt file in the Documentation/filesystems subdirectory of your kernel sources for those and other XFS mount options.
In general you should get about the same or better performance values with XFS in various benchmarks. One thing XFS is usually bad at is removing large amounts of files (rm -rf or bonnie++).
This is fixed in the current code (mid-march). But also before this is normal and harmless - it only takes a bit of time (on boot and halt with SuSE startup scripts - only on halt with RedHat based scripts).
<& xfsTemplate,bottom=>1 &>