xfs(4)xfs(4)NAMExfs - layout of the XFS filesystem
DESCRIPTION
An XFS filesystem can reside on a regular disk partition or on a logical
volume (see lv(7M) and xlv(7M)). An XFS filesystem has up to three
parts: a data section, a log section, and a real-time section. For disk
partition and lv logical volume filesystems, the real-time section is
absent, and the log area is contained within the data section. For XLV
logical volume filesystems, the real-time section is optional, and the
log section can be separate from the data section or contained within it.
The filesystem sections are divided into a certain number of blocks,
whose size is specified at mkfs(1M) time with the -b option.
The data section contains all the filesystem metadata (inodes,
directories, indirect blocks) as well as the user file data for ordinary
(non-real-time) files and the log area if the log is internal to the data
section. The data section is divided into a number of allocation groups.
The number and size of the allocation groups are chosen by mkfs so that
there is normally a small number of equal-sized groups. The number of
allocation groups controls the amount of parallelism available in file
and block allocation. It should be increased from the default if there
is sufficient memory and a lot of allocation activity. The number of
allocation groups should not be set very high, since this can cause large
amounts of CPU time to be used by the filesystem, especially when the
filesystem is nearly full. More allocation groups are added (of the
original size) when xfs_growfs(1M) is run.
The log section (or area, if it is internal to the data section) is used
to store changes to filesystem metadata while the filesystem is running
until those changes are made to the data section. It is written
sequentially during normal operation and read only during mount. When
mounting a filesystem after a crash, the log is read to complete
operations that were in progress at the time of the crash.
The real-time section is used to store the data of real-time files.
These files had an attribute bit set through fcntl(2) after file
creation, before any data was written to the file. The real-time section
is divided into a number of extents of fixed size (specified at mkfs
time). Each file in the real-time section has an extent size that is a
multiple of the real-time section extent size.
Each allocation group contains several data structures. The first sector
contains the superblock. For allocation groups after the first, the
superblock is just a copy and is not updated after mkfs. The next three
sectors contain information for block and inode allocation within the
allocation group. Also contained within each allocation group are data
structures to locate free blocks and inodes; these are located through
the header structures.
Page 1
xfs(4)xfs(4)
Each XFS filesystem is labeled with a unique universal identifier (UUID).
(See uuid(3C) for more details.) The UUID is stored in every allocation
group header and is used to help distinguish one XFS filesystem from
another, therefore you should avoid using dd or other block-by-block
copying programs to copy XFS filesystems. If two XFS filesystems on the
same machine have the UUID, xfsdump may become confused when doing
incremental and resumed dumps. (See xfsdump(1M) for more details.)
xfs_copy or xfsdump/xfsrestore are recommended for making copies of XFS
filesystems.
All these data structures are subject to change, and the headers that
specify their layout on disk are not provided.
SEE ALSOattr(1), grio(1M), mkfs(1M), mkfs_xfs(1M), xfs_bmap(1M), xfs_check(1M),
xfs_copy(1M), xfs_estimate(1M), xfs_growfs(1M), xfs_logprint(1M),
xfs_repair(1M), xfsdump(1M), xfsrestore(1M), fcntl(2), syssgi(2),
uuid(3C), filesystems(4), lv(7M), xlv(7M).
Page 2
