Quick links:
http://oss.sgi.com/projects/xfs/faq.html
Many thanks to earlier maintainers of this document - Thomas Graichen and Seth Mos.
The SGI XFS project page http://oss.sgi.com/projects/xfs/ is the definitive reference. It contains pointers to whitepapers, books, articles, etc.
You could also join the linux-xfs mailing list, and there is also the #xfs IRC channel on irc.freenode.net.
Andreas Gruenbacher maintains the Extended Attribute and POSIX ACL documentation for Linux at http://acl.bestbits.at/
The acl(5) manual page is also quite extensive.
Linux native filesystem (83).
There are a number of mount options influencing XFS filesystems - refer to the mount(8) maunal page or the documentation in the kernel source tree itself (Documentation/filesystems/xfs.txt)
No, there is no relation. Newer utilities tend to mainly have fixes and checks the previous versions might not have. New features are also added in a backward compatible way - if they are enabled via mkfs, an incapable (old) kernel will recognize that it does not understand the new feature, and refuse to mount the filesystem.
XFS runs on all of the platforms that Linux supports. It is more tested on the more common platforms, especially the i386 family. Its also well tested on the IA64 platform since thats the platform SGI Linux products use.
Yes.
To use quotas with XFS, you need to enable XFS quota support when you configure your kernel. You also need to specify quota support when mounting. You can get the quota utilities at their sourceforge website http://sourceforge.net/projects/linuxquota/.
xfsdump(8) and xfsrestore(8) are fully supported. The tape format is the same as on IRIX, so tapes are interchangeable between the two operating systems.
This depends on where you install LILO.
Yes, for MBR (Master Boot Record) installations.
No, for root partition installations because the XFS superblock is written at block zero, where LILO would be installed. This is to maintain compatibility with the IRIX on-disk format, and will not be changed.
There is native XFS filesystem support for GRUB starting with version 0.91 and onward. Unfortunately, GRUB used to make incorrect assumptions about being able to read a block device image while a filesystem is mounted and actively being written to, which could cause intermittent problems when using XFS. This has reportedly since been fixed, and the 0.97 version (at least) of GRUB is apparently stable.
Yes.
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 (i.e. unmounted). If you plan to use IRIX filesystems on Linux keep the following points in mind: the kernel needs to have SGI partition support enabled; there is no XLV support in Linux, so you are unable to read IRIX filesystems which use the XLV volume manager; also not all blocksizes available on IRIX are available on Linux (only blocksizes less than or equal to the pagesize of the architecture: 4k for i386, ppc, ... 8k for alpha, sparc, ... is possible for now). Make sure that the directory format is version 2 on the IRIX filesystems (this is the default since IRIX 6.5.5). Linux can only read v2 directories.
You can NOT make a XFS partition smaller online. The only way to shrink is to do a complete dump, mkfs and restore.
An XFS filesystem may be enlarged by using xfs_growfs(8).
If using partitions, you need to have free space after this partition to do so. Remove partition, recreate it larger with the exact same starting point. Run xfs_growfs to make the partition larger. Note - editing partition tables is a dangerous passtime, so back up your filesystem before doing so.
Using XFS filesystems on top of a volume manager makes this alot easier.
Things to include are what version of XFS you are using, if this is a CVS version of what date and version of the kernel. If you have problems with userland packages please report the version of the package you are using.
If the problem relates to a particular filesystem, the output from the xfs_info(8) command and any mount(8) options in use will also be useful to the developers.
If you experience an oops, please run it through ksymoops so that it can be interpreted.
If mount prints an error message something like:
mount: /dev/hda5 has wrong major or minor number
you either do not 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.
If you get something like:
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
or too many mounted file systems
Refer to your system log file (/var/log/messages) for a
detailed diagnostic message from the kernel.
There is no undelete in XFS. Always keep backups.
You can backup a XFS filesystem with utilities like xfsdump(8) and standard tar(1) for standard files. If you want to backup ACLs you will need to use xfsdump, this is the only tool at the moment that supports backing up extended attributes. xfsdump can also be integrated with amanda(8).
The error 990 stands for EFSCORRUPTED which usually means XFS has detected a filesystem metadata problem and has shut the filesystem down to prevent further damage.
The cause can be pretty much anything, unfortunately - filesystem, virtual memory manager, volume manager, device driver, or hardware.
There should be a detailed console message when this initially happens. The messages have important information giving hints to developers as to the earliest point that a problem was detected. It is there to protect your data.
XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash.
Since XFS does not write data out immediately unless you tell it to with fsync, an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are looking at an inode which was flushed out, but whose data was not. Typically you'll find that the inode is not taking any space since all it has is a size but no extents allocated (try examining the file with the xfs_bmap(8) command).
<& xfsTemplate,bottom=>1 &>