XFS

XFS is a high-performance journaling file system created to replace EFS on IRIX, first appearing in IRIX 6.1. XFS increased volume size, marked a move from a synchronous filesystem to a journaled filesystem, and

History

XFS is among the oldest journaling file systems available for UNIX systems, and has a mature, stable and well-debugged codebase. Development of XFS was started by Silicon Graphics in 1993, with first deployment being seen on IRIX 6.1 in 1994. The filesystem was later released under the GNU General Public License in May 2000, and ported to GNU/Linux, with the first distribution support appearing in 2001/2002.

Specifications

Capacity

XFS is a 64-bit file system. It supports a maximum file system size of 8 binary exabytes minus one byte, though this is subject to block limits imposed by the host operating system. IRIX is known to support up to 8 terabyte volumes.

Directory Structure	B+ Trees
File Contents	B+ Trees
Max Volume Size	8 Terabytes
Max File Size	4 Terabytes
Max Filename Length	255 Bytes

Interoperability with Linux XFS

A modern GNU/Linux distribution is unable to safely read or write to XFS volumes created by IRIX. Data loss will occur!

Since XFS was eventually moved to GNU/Linux for primary development, it has moved onto directory structure v3, v4 and v5, all of which are incompatible. Directory structure v2 support, the last IRIX supported version, was removed in kernel 3.17. All versions of GNU/Linux using a later kernel are unable to safely do anything to an XFS system.

From the source code:

 * Version 3 includes:
 *
 *    - a larger block header for CRC and identification purposes and so the
 *    offsets of all the structures inside the blocks are different.
 *
 *    - new magic numbers to be able to detect the v2/v3 types on the fly.
 */

This implies that the v2 and v3 headers are different. We later see in the code:

/*
 * define a structure for all the verification fields we are adding to the
 * directory block structures. This will be used in several structures.
 * The magic number must be the first entry to align with all the dir2
 * structures so we determine how to decode them just by the magic number.
 */
struct xfs_dir3_blk_hdr {
    __be32            magic;    /* magic number */
    __be32            crc;    /* CRC of block */
    __be64            blkno;    /* first block of the buffer */
    __be64            lsn;    /* sequence number of last write */
    uuid_t            uuid;    /* filesystem we belong to */
    __be64            owner;    /* inode that owns the block */
};

The headers are different. Per GitHub dev rozjin, if a v3 or later only driver tries to write to XFS v2:

/*
 * Active entry in a data block.
 *
 * Aligned to 8 bytes.  After the variable length name field there is a
 * 2 byte tag field, which can be accessed using xfs_dir3_data_entry_tag_p.
 *
 * For dir3 structures, there is file type field between the name and the tag.
 * This can only be manipulated by helper functions. It is packed hard against
 * the end of the name so any padding for rounding is between the file type and
 * the tag.
 */
typedef struct xfs_dir2_data_entry {
    __be64            inumber;    /* inode number */
    __u8            namelen;    /* name length */
    __u8            name[];        /* name bytes, no null */
     /* __u8            filetype; */    /* type of inode we point to */
     /*    __be16                  tag; */        /* starting offset of us */
} xfs_dir2_data_entry_t;

The modern driver will write a header with a type, which will be interpreted as the start offset tag, but in reality is a type. This will break the filesystem under IRIX, and it's not correct per XFS either.