xfs - layout of the XFS filesystem
An XFS filesystem can reside on a regular disk partition or on a logical
volume (see l
). 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.
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
All these data structures are subject to change, and the headers that
specify their layout on disk are not provided.
attr(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).
filesystems: cdfs, dos, fat, EFS, hfs, mac, iso9660, cd-rom, kfs, nfs,
XFS, rockridge - IRIX filesystem types
IRIX supports a number of different filesystems. Some of these types are
names that can be used with the mount(1) command's -t option. Others are
just common names and cannot be used with the mount command. An example
of this is the RockRidge type, which is a superset of the iso9660
filesystem type. Therefore RockRidge filesystems are mounted with a
command similar to this:
mount -t iso9660 -o ro /dev/rdsk/dks0d3vol /CDROM
The following filesystem types are supported:
bds Not a file system type, an extension to NFS for bulk data
transfers. The BDSpro server is an optional product and must
be purchased separately.
Same as type iso9660 (see below); this is the ABI compliant
dos (fat) The filesystem used by many personal computers. Types 1, 4,
and 6 are supported, included long names where supported.
Type 5 (extended partitions) are supported only if mounted
with the partition # options. IRIX support for dos
filesystems is restricted to removable disk devices such as
floppy and floptical disks. Filenames on dos filesystems are
restricted to up to an eight character name followed by an
optional period and three character filename extension, for
most types. Longer names are supported to a limited degree,
on the types where the native OS supports them.
EFS The older extent-based disk filesystem used by IRIX for disks
and also for IRIX software distribution CD-ROMs. See efs(4)
for more details.
fd A filesystem used to access process file descriptors.
hfs (mac) The filesystem used by Macintosh computers. IRIX support for
hfs filesystems is restricted to removable disk devices such
as floppy and floptical disks and to CD-ROMs. A hfs file is
composed of three portions: a data fork, a resource fork,
and a desktop information entry. The data fork appears in a
normal directory. The resource fork in a special directory
(.HSResource) in the file's directory. The desktop
information for all files in a directory is contained in the
special file .HSancillary.
A CD-ROM filesystem type conforming to ISO standard 9660.
iso9660 CD-ROMs are used when the contents of the CD-ROM is
intended to be readable by a variety of operating systems.
You must install the optional subsystem eoe.sw.cdrom to be
able to mount and read an iso9660 CD-ROM. Also see RockRidge
below. Note that IRIX software distribution CD-ROMs are not
iso9660 filesystems, they are efs filesystems. Music CDs are
not file structured and are not used as filesystems. Music
CDs can be played using the CD-ROM drive using cdman(1) or
kfs A network filesystem used to access disks on located on
remote computers using AppleShare networking. Generally,
AppleShare networking is used to access Macintosh computers.
Except for the disk location, kfs filesystems are identical
to hfs filesystems.
nfs A network filesystem used to access disks located on remote
computers. Both NFS Version 2, and NFS Version 3 are
supported. NFS is an optional product and must be purchased
separately. The subsystem nfs.sw.nfs must be installed to
proc A filesystem that provides access to the image of each active
process in the system.
hwgfs A filesystem that provides access to the system hardware
RockRidge A filesystem layered on type of the iso9660 filesystem type
(see above) that provides semantics closer to those of
standard UNIX filesystems. In particular, it supplies file
permissions and allows for directory hierarchies more than 8
XFS The next-generation 64-bit high performance journaling
filesystem used by IRIX for disks. See xfs(4) for more
cachefs A caching filesystem for use with efs, xfs, nfs, nfs3,
iso9660, hfs, dos, kfs, and cdfs. See cachefs(4) for
The nfs and kfs filesystems are optional products. Support for iso9660
filesystems is in the optional subsystem eoe.sw.cdrom.
IRIX implements dos, hfs, iso9660, and kfs filesystems as user mode NFS
daemons. In some cases errors detected by these daemons are reported as
NFS errors. Although NFS is a product option, support for these
filesystem types is not dependent on the installation of NFS.
exportfs(1M), fpck(1M), fsck(1M), mediad(1M), mkfp(1M), mkfs(1M),
mount(1M), mount_kfs(1M), efs(4), fd(4), fstab(4), hwgfs(4), proc(4),
PPPPaaaaggggeeee 3333 [ Back ]