[BACK]Return to xfs.html CVS log [TXT][DIR] Up to [Development] / xfs-website.orig / manpages
File: [Development] / xfs-website.orig / manpages / xfs.html (download) (as text)

Revision 1.3, Wed Sep 27 05:01:47 2000 UTC (17 years, 1 month ago) by xfs
Branch: MAIN
Changes since 1.2: +6 -6 lines 

Update manpages.
These changes from Martin Peterson.

<html>
<head>
<meta name="Content-Style" content="text/css">
</head>
<body>
<a href="#NAME">NAME</a><br>
<a href="#DESCRIPTION">DESCRIPTION</a><br>
<a href="#SEE ALSO">SEE ALSO</a><br>
<!-- Creator     : groff version 1.15  -->
<!-- CreationDate: Tue Sep 26 23:59:40 2000
 -->
<!-- Total number of pages: 1 -->
<!-- Page: 1 -->
<!-- left  margin: 100 -->
<!-- right margin: 750 -->
<a name="NAME"></a><h2>NAME</h2><p><font size=3>xfs - layout of the XFS filesystem</p>
<a name="DESCRIPTION"></a><h2>DESCRIPTION</h2><p><font size=3>An XFS filesystem can reside on a regular disk partition or on a logical volume (see <font size=3><I>lvm</I><font size=3>(8)). An XFS filesystem has up to three parts: a data section, a log section, and a real-time section. For disk partition filesystems, the real- time section is absent, and the log area is contained within the data section. For 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 <font size=3><I>blocks</I><font size=3>, whose size is specified at <font size=3><I>mkfs</I><font size=3>(8) time with the <font size=3><B>-b</B> <font size=3>option.</p>
<p><font size=3>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 <font size=3><I>internal</I> <font size=3>to the data section. The data section is divided into a number of <font size=3><I>allocation groups</I><font size=3>. The number and size of the allocation groups are chosen by <font size=3><I>mkfs</I> <font size=3>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 <font size=3><I>xfs_growfs</I><font size=3>(8) is run.</p>
<p><font size=3>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 oper- ations that were in progress at the time of the crash.</p>
<p><font size=3>The real-time section is used to store the data of real-time files. These files had an attribute bit set through <font size=3><I>fcntl</I><font size=3>(2) after file creation, before any data was written to the file. The real-time section is divided into a number of <font size=3><I>extents</I> <font size=3>of fixed size (specified at <font size=3><I>mkfs</I> <font size=3>time). Each file in the real-time section has an extent size that is a multiple of the real-time section extent size.</p>
<p><font size=3>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 <font size=3><I>mkfs</I><font size=3>. 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.</p>
<p><font size=3>Each XFS filesystem is labeled with a unique universal identifier (UUID). 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 <font size=3><I>dd</I> <font size=3>or other block-by-block copying programs to copy XFS filesystems. If two XFS filesystems on the same machine have the UUID, <font size=3><I>xfsdump</I> <font size=3>may become confused when doing incremental and resumed dumps. (See <font size=3><I>xfsdump</I><font size=3>(8) for more details.) <font size=3><I>xfs_copy</I> <font size=3>or <font size=3><I>xfsdump</I><font size=3>/<font size=3><I>xfsrestore</I> <font size=3>are recommended for making copies of XFS filesystems.</p>
<p><font size=3>All these data structures are subject to change, and the headers that specify their layout on disk are not provided.</p>
<a name="SEE ALSO"></a><h2>SEE ALSO</h2><p><font size=3>fs(5), mkfs.xfs(8), xfs_bmap(8), xfs_check(8), xfs_copy(8), xfs_estimate(8), xfs_growfs(8), xfs_logprint(8), xfs_repair(8), xfsdump(8), xfsrestore(8), fcntl(2), lvm(8).<br>
</p>
</body>
</html>