You must take the following issues into account when you create and administer XFS filesystems with the current release of XFS for Linux.
Currently XFS is limited to filesystems smaller that 2 terabytes. This is due to limitations in the Linux block device I/O layers.
The XFS team is working with Linux developers to improve the Linux I/O layers. The improvements will include the support neccesary to exceed 2 Tbyte filesystems.
XFS has mostly been tested on machines with less than 1 Gbyte of memory with highmem support turned off. Highmem kernels with XFS do function, provided the kio and kiocluster mount options are not used; however, less testing has been performed in this configuration.
Due to known problems with later versions of gcc, version 2.91.66 must be used when compiling XFS and the associated kernel. This is the default compiler on RedHat 6.2 systems. Other distributions may be using a later version. The easiest way to check what version is in use is by running gcc -v.
The version of glibc primarily used for development and testing has been 2.1.3. Other versions should be considered "status unknown".
A preliminary set of system calls to support extended attributes has been added. This interface will most likely change as it becomes more defined and other Linux developers contribute their thoughts.
The Linux version of dump and restore can be used to migrate data from a non-XFS volume to an XFS volume. Linux dump, however, cannot be used to dump an XFS volume as it uses ext2 library functions.
xfsdump and xfsrestore can be used to migrate an IRIX XFS volume to a Linux XFS volume and vice versa. However, one needs to set the block-size explicitly for Linux xfsdump and xfstrestore to match the block-size used on IRIX. This is done by using the -b option, and would typically be set to -b 2097152 or to -b 245760 for a remotely dumped IRIX tape. Also, there is currently a bug in xfsrestore which will cause it to core dump at the end of the restore if the host does not have any on-disk inventory. If this happens all the files will be restored but the directory attributes (modes, permissions and dates) will not be restored. The work-around is to use the -J option to xfsrestore which will prevent it from trying to update the on-disk inventory from the tape inventory. Both of these problems are planned to be fixed in the next release.
xfsdump and xfsrestore should be used for backup and restore of XFS volumes. xfsdump and xfsrestore currently support file extents but not extended attributes. DMAPI and quotas are not yet supported in Linux XFS, nor are they supported in xfsdump and xfsrestore.
XFS supports two directory formats, referred to as version 1 and version 2. For Linux XFS, the version 2 directory format is strongly recommended. Due to the way glibc getdents interfaces with the kernel implementation, XFS version 1 directories can exhibit problems, usually missing directory entries. By default mkfs will create version 2 directory format filesystems.
For the current release of XFS, the filesystem block size is limited to the size of a memory page. On a x86 architecture that size is 4 Kbytes.
Note that files systems created on an IRIX/MIPS platform must have been created with a 4 Kbyte block size in order to be mounted on a ia32 Linux system. File systems not created with a 4k block will fail to mount with an error indicating the mis-match.
The external log format will be changing in the future, and is therefore unsupported.
The unwritten extent feature is not yet operational and should be turned off when mkfs is executed, using the following argument to the mkfs command:
-d unwritten=0
Currently this is the default setting for mkfs.xfs on Linux.
Specifying O_SYNC on open will not have the desired effect. write system calls can return before data is on disk. fsync will force data out to disk. This will be fixed in a later beta.
It is scheduled for a later beta release.
Support for filesystem quotas is not yet operational.
It is possible to remount an XFS filesystem to change its permissions from read/write to read-only. This support is needed for XFS to function as a root filesystem.
Note: This operation will most likely result in a hung file system if performed on a busy partition.
Issuing the remount call to a non-busy XFS filesystem does not always work correctly. The usual result will be a hung processes. The occurs primarily when executing the mount -o remount command.
Mounting files using the loop filesystem on an XFS partition does not work and usually results in a system panic.