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. Also keep in mind that currently the option for using kiobufs only works on scsi drives. 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). 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 directory. The tools also have man-pages which you may consult for interesting options like:
mkfs -t xfs -l size=16000b /dev/foo
which sets the log size within the filesystem. In the near future the mkfs.xfs in the build tree will also be changed to mkfs.xfs so that there is less confusion with names. 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.
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 con- tains 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 am using 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 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).
XFS on linux/ppc seems to be running quite stable now (you may get a diff to the SGI XFS cvs tree as file ppc-xfs-diff.000914 from the link below) and the last time i tried it on the alpha it had some bugs in it - but i will have a fresh look at the alpha again now that it is up and running on ppc. Once it is running on these two I expect no bigger problems on other arches because we then have all the little/big-endian and 32/64 bit stuff tested.
If you are interested in this you may have a look at
Not at the moment - but XFS usually has quota support (as one would expect from a modern filesystem). The question is how to use them on the linux port: the linux or the IRIX way. This has to be ironed out and implemented but I think they will appear in the not too distant future.
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 they should work fine for things like Amanda. Dumps produced with standard Unix dump may be restored onto an XFS filesystem. From now on (about 2000/08/17) they should start to be useable.
No it does not work correctly. For now you have to use an ext2 /boot partition. But this should be fixed soon.
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.
No currently not.
In principle yes - but there has to be added some code so that the unmounting so that it works in a clean way. So it is better to wait a bit with it. (But it definitely works - I tried it this way)
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.
Nobody has tested it so far but expect it not to work like for all the other journaling filesystems due to internal buffer locking problems I think. If anyone tries this - please let me know. 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.
I have not deeply tested it - for light tests it worked - but it has to be investigated deeper. If anyone has more details here - please let me know.
An XFS filesystem may be enlarged within a partition using xfs_growfs. This tool should be used with caution, particularly until the release is stabilised.
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).
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 egcs instead of gcc 2.95 this should fix your problem.
Yes. So far there were some problems reported with kernels built with gcc 2.95 which were solved by compiling it with egcs. So for now please use egcs to build your XFS kernel.
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 (work in progress), fsr - xfs_fsr is a defragmenter for xfs (work in progress), repair - xfs_repair is the consistency checker for an xfs filesystem (working).
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.
<& xfsTemplate,bottom=>1 &>