XFS FUSE Implementation (Week 6)

In the standard Unix filesystem there are components called symbolic links. These are nodes that point to other nodes. They usually contains the path of the node they are pointing to. But, how is this path stored?

Symbolic Links are stored locally if the path is small enough. This means that the format will be "local". And the data will be in the form of an array of charachters.

If the length of the symbolic link exceeds the space available in the inode’s data fork, the link is moved to a new filesystem block and the inode’s format is changed to “extents”. In the significant majority of cases, this will be in one filesystem block as a symlink cannot be longer than 1024 characters.

Each block will start with the following structure:

struct xfs_dsymlink_hdr {
  __be32 sl_magic;
  __be32 sl_offset;
  __be32 sl_bytes;
  __be32 sl_crc;
  uuid_t sl_uuid;
  __be64 sl_owner;
  __be64 sl_blkno;
  __be64 sl_lsn;


  1. sl_magic: Specifies the magic number for the symlink block: ”XSLM” (0x58534c4d).
  2. sl_offset: Offset of the symbolic link target data, in bytes.
  3. sl_bytes: Number of bytes used to contain the link target data.
  4. sl_crc: Checksum of the symlink block.
  5. sl_uuid: The UUID of this block, which must match either sb_uuid or sb_meta_uuid depending on which features are set.
  6. sl_owner: The inode number that this symlink block belongs to.
  7. sl_blkno: Disk block number of this symlink.
  8. sl_lsn: Log sequence number of the last write to this block.

This is directly followed by the path in the form of a character array.


Files are the building blocks of any filesystem. You can think of them as an arbitrary vector of bytes. So, just like symlinks it's just an array of bytes. But, it can be huge in the order of terabyte or larger.

The FUSE kernel module sends requests with the following parameters (inode, offset, size). We have to reply with exactly size bytes starting from offset offset and reply with an EOF if the remaining data is smaller than the request size.

Extent List Files

Theses are files which can be expressed in an extent list that fits in the inode. Inodes can usually carry up to 23 extens. So if the filesystem is sparse enough an extent list file can carry only (23 * block size). It's a simple matter of extracting the logical block number using modulo arithmetic and then mapping it to a filesystem block using the extent list.

B+Tree Files

When the extent list is exhausted the records are transformed into a B+Tree. Which can be navigated the same way the Fixed Length B+Tree was in directories.


SummerOfCode2021Projects/XFSFUSEImplementation/Week6 (last edited 2021-08-22T18:11:35+0000 by KhaledEmaraDev)