xfs · shipping · also XFS filesystem

XFS

XFS is an extent-based journaling filesystem that divides its data section into allocation groups and uses B-trees for filesystem metadata.

Related Observatory article: XFS on hesela.com

XFS originated on SGI IRIX and is also implemented in Linux. Its data section is divided into allocation groups to support parallel allocation work. It has a log section and can have a separate realtime section; the log may be internal or on another device. Allocation groups are parts of one filesystem, not independent recovery copies. [1] [2]

XFS journals metadata through write-ahead logging. In the Linux v6.16 design, delayed logging combines repeated metadata changes before writing a checkpoint. An in-memory transaction commit can therefore precede persistence in the journal. Ordinary file-data writes are distinct from these metadata transactions. [3]

For application durability, use a synchronization protocol and check its results; synchronizing a file alone does not guarantee persistence of its containing directory entry. The recovery machinery can replay recorded changes and finish work described by intent records, but a chain of rolling transactions is not one atomic journal transaction. Follow the related logging records for those internal boundaries. [4] [3]

With metadata CRCs enabled, self-describing metadata combines CRC32c with filesystem identity, block location and object-specific ownership. A matching CRC alone does not detect a byte-identical block written to the wrong location; identity checks supply that context. These metadata checks are not file-content checksums or a proof of all cross-block relationships. [5] [6]

Relations

related

XFS Active Item List, XFS Committed Item List, XFS deferred operation, XFS delayed logging, XFS intent log item, XFS relogging, XFS rolling transaction, Inode, File extent, Delayed allocation, Write-ahead log, fsync, Checksum, Filesystem consistency invariant, Read-only mount

Limitations

• A read-only mount can still perform internal log-recovery writes. The norecovery option requires read-only mounting and suppresses recovery; after an unclean shutdown this can expose inconsistent state and inaccessible files or directories. [7, 2]

Citations

1. Linux v6.16: XFS overview, extents, B-trees and filesystem sections (accessed 2026-10-24)
2. xfsprogs xfs(5): data, log and realtime sections; allocation groups (accessed 2026-10-24)
3. Linux v6.16: XFS Logging Design, metadata transactions and asynchronous commits (accessed 2026-10-24)
4. Linux man-pages fsync(2): file and directory synchronization (accessed 2026-10-24)
5. Linux v6.16: XFS Self Describing Metadata, location, ownership and runtime validation (accessed 2026-10-24)
6. xfsprogs mkfs.xfs(8): metadata crc option (accessed 2026-10-24)
7. Linux v6.16: xfs_log_writable permits internal recovery writes on read-only mounts (accessed 2026-10-24)

JSON: /data/terms/xfs.json