1xfs(5) File Formats Manual xfs(5)
2
6 xfs - layout, mount options, and supported file attributes for the XFS
7 filesystem
8
10 An XFS filesystem can reside on a regular disk partition or on a logi‐
11 cal volume. An XFS filesystem has up to three parts: a data section, a
12 log section, and a realtime section. Using the default mkfs.xfs(8) op‐
13 tions, the realtime section is absent, and the log area is contained
14 within the data section. The log section can be either separate from
15 the data section or contained within it. The filesystem sections are
16 divided into a certain number of blocks, whose size is specified at
17 mkfs.xfs(8) time with the -b option.
18 The data section contains all the filesystem metadata (inodes, directo‐
20 ries, indirect blocks) as well as the user file data for ordinary (non-
21 realtime) files and the log area if the log is internal to the data
22 section. The data section is divided into a number of allocation
23 groups. The number and size of the allocation groups are chosen by
24 mkfs.xfs(8) so that there is normally a small number of equal-sized
25 groups. The number of allocation groups controls the amount of paral‐
26 lelism available in file and block allocation. It should be increased
27 from the default if there is sufficient memory and a lot of allocation
28 activity. The number of allocation groups should not be set very high,
29 since this can cause large amounts of CPU time to be used by the
30 filesystem, especially when the filesystem is nearly full. More allo‐
31 cation groups are added (of the original size) when xfs_growfs(8) is
32 run.
33 The log section (or area, if it is internal to the data section) is
35 used to store changes to filesystem metadata while the filesystem is
36 running until those changes are made to the data section. It is writ‐
37 ten sequentially during normal operation and read only during mount.
38 When mounting a filesystem after a crash, the log is read to complete
39 operations that were in progress at the time of the crash.
40 The realtime section is used to store the data of realtime files.
42 These files had an attribute bit set through xfsctl(3) after file cre‐
43 ation, before any data was written to the file. The realtime section
44 is divided into a number of extents of fixed size (specified at
45 mkfs.xfs(8) time). Each file in the realtime section has an extent
46 size that is a multiple of the realtime section extent size.
47 Each allocation group contains several data structures. The first sec‐
49 tor contains the superblock. For allocation groups after the first,
50 the superblock is just a copy and is not updated after mkfs.xfs(8).
51 The next three sectors contain information for block and inode alloca‐
52 tion within the allocation group. Also contained within each alloca‐
53 tion group are data structures to locate free blocks and inodes; these
54 are located through the header structures.
55 Each XFS filesystem is labeled with a Universal Unique Identifier
57 (UUID). The UUID is stored in every allocation group header and is
58 used to help distinguish one XFS filesystem from another, therefore you
59 should avoid using dd(1) or other block-by-block copying programs to
60 copy XFS filesystems. If two XFS filesystems on the same machine have
61 the same UUID, xfsdump(8) may become confused when doing incremental
62 and resumed dumps. xfsdump(8) and xfsrestore(8) are recommended for
63 making copies of XFS filesystems.
64
66 Some functionality specific to the XFS filesystem is accessible to ap‐
67 plications through the xfsctl(3) and by-handle (see open_by_handle(3))
68 interfaces.
69
71 The following XFS-specific mount options may be used when mounting an
72 XFS filesystem. Other generic options may be used as well; refer to the
73 mount(8) manual page for more details.
74 allocsize=size
76 Sets the buffered I/O end-of-file preallocation size when doing
77 delayed allocation writeout. Valid values for this option are
78 page size (typically 4KiB) through to 1GiB, inclusive, in power-
79 of-2 increments.
80 The default behavior is for dynamic end-of-file preallocation
82 size, which uses a set of heuristics to optimise the prealloca‐
83 tion size based on the current allocation patterns within the
84 file and the access patterns to the file. Specifying a fixed al‐
85 locsize value turns off the dynamic behavior.
86 attr2|noattr2
88 Note: These options have been deprecated as of kernel v5.10; The
89 noattr2 option will be removed no earlier than in September 2025
90 and attr2 option will be immutable default.
91 The options enable/disable an "opportunistic" improvement to be
93 made in the way inline extended attributes are stored on-disk.
94 When the new form is used for the first time when attr2 is se‐
95 lected (either when setting or removing extended attributes) the
96 on-disk superblock feature bit field will be updated to reflect
97 this format being in use.
98 The default behavior is determined by the on-disk feature bit
100 indicating that attr2 behavior is active. If either mount option
101 it set, then that becomes the new default used by the filesys‐
102 tem.
103 CRC enabled filesystems always use the attr2 format, and so will
105 reject the noattr2 mount option if it is set.
106 dax=value
108 Set CPU direct access (DAX) behavior for the current filesystem.
109 This mount option accepts the following values:
110 "dax=inode" DAX will be enabled only on regular files with
112 FS_XFLAG_DAX applied.
113 "dax=never" DAX will not be enabled for any files. FS_XFLAG_DAX
115 will be ignored.
116 "dax=always" DAX will be enabled for all regular files, regard‐
118 less of the FS_XFLAG_DAX state.
119 If no option is used when mounting a filesystem stored on a DAX
121 capable device, dax=inode will be used as default.
122 For details regarding DAX behavior in kernel, please refer to
124 kernel's documentation at filesystems/dax.txt
125 discard|nodiscard
127 Enable/disable the issuing of commands to let the block device
128 reclaim space freed by the filesystem. This is useful for SSD
129 devices, thinly provisioned LUNs and virtual machine images, but
130 may have a performance impact.
131 Note: It is currently recommended that you use the fstrim appli‐
133 cation to discard unused blocks rather than the discard mount
134 option because the performance impact of this option is quite
135 severe. For this reason, nodiscard is the default.
136 grpid|bsdgroups|nogrpid|sysvgroups
138 These options define what group ID a newly created file gets.
139 When grpid is set, it takes the group ID of the directory in
140 which it is created; otherwise it takes the fsgid of the current
141 process, unless the directory has the setgid bit set, in which
142 case it takes the gid from the parent directory, and also gets
143 the setgid bit set if it is a directory itself.
144 filestreams
146 Make the data allocator use the filestreams allocation mode
147 across the entire filesystem rather than just on directories
148 configured to use it.
149 ikeep|noikeep
151 Note: These options have been deprecated as of kernel v5.10; The
152 noikeep option will be removed no earlier than in September 2025
153 and ikeep option will be immutable default.
154 When ikeep is specified, XFS does not delete empty inode clus‐
157 ters and keeps them around on disk. When noikeep is specified,
158 empty inode clusters are returned to the free space pool.
159 noikeep is the default.
160 inode32|inode64
162 When inode32 is specified, it indicates that XFS limits inode
163 creation to locations which will not result in inode numbers
164 with more than 32 bits of significance.
165 When inode64 is specified, it indicates that XFS is allowed to
167 create inodes at any location in the filesystem, including those
168 which will result in inode numbers occupying more than 32 bits
169 of significance.
170 inode32 is provided for backwards compatibility with older sys‐
172 tems and applications, since 64 bits inode numbers might cause
173 problems for some applications that cannot handle large inode
174 numbers. If applications are in use which do not handle inode
175 numbers bigger than 32 bits, the inode32 option should be speci‐
176 fied.
177 For kernel v3.7 and later, inode64 is the default.
179 largeio|nolargeio
181 If "nolargeio" is specified, the optimal I/O reported in st_blk‐
182 size by stat(2) will be as small as possible to allow user ap‐
183 plications to avoid inefficient read/modify/write I/O. This is
184 typically the page size of the machine, as this is the granular‐
185 ity of the page cache.
186 If "largeio" specified, a filesystem that was created with a
188 "swidth" specified will return the "swidth" value (in bytes) in
189 st_blksize. If the filesystem does not have a "swidth" specified
190 but does specify an "allocsize" then "allocsize" (in bytes) will
191 be returned instead. Otherwise the behavior is the same as if
192 "nolargeio" was specified. nolargeio is the default.
193 logbufs=value
195 Set the number of in-memory log buffers. Valid numbers range
196 from 2–8 inclusive.
197 The default value is 8 buffers.
199 If the memory cost of 8 log buffers is too high on small sys‐
201 tems, then it may be reduced at some cost to performance on
202 metadata intensive workloads. The logbsize option below controls
203 the size of each buffer and so is also relevant to this case.
204 logbsize=value
206 Set the size of each in-memory log buffer. The size may be
207 specified in bytes, or in kibibytes (KiB) with a "k" suffix.
208 Valid sizes for version 1 and version 2 logs are 16384
209 (value=16k) and 32768 (value=32k). Valid sizes for version 2
210 logs also include 65536 (value=64k), 131072 (value=128k) and
211 262144 (value=256k). The logbsize must be an integer multiple of
212 the log stripe unit configured at mkfs time.
213 The default value for version 1 logs is 32768, while the default
215 value for version 2 logs is max(32768, log_sunit).
216 logdev=device and rtdev=device
218 Use an external log (metadata journal) and/or real-time device.
219 An XFS filesystem has up to three parts: a data section, a log
220 section, and a real-time section. The real-time section is op‐
221 tional, and the log section can be separate from the data sec‐
222 tion or contained within it.
223 noalign
225 Data allocations will not be aligned at stripe unit boundaries.
226 This is only relevant to filesystems created with non-zero data
227 alignment parameters (sunit, swidth) by mkfs.
228 norecovery
230 The filesystem will be mounted without running log recovery. If
231 the filesystem was not cleanly unmounted, it is likely to be in‐
232 consistent when mounted in "norecovery" mode. Some files or di‐
233 rectories may not be accessible because of this. Filesystems
234 mounted "norecovery" must be mounted read-only or the mount will
235 fail.
236 nouuid Don't check for double mounted file systems using the file sys‐
238 tem uuid. This is useful to mount LVM snapshot volumes, and of‐
239 ten used in combination with "norecovery" for mounting read-only
240 snapshots.
241 noquota
243 Forcibly turns off all quota accounting and enforcement within
244 the filesystem.
245 uquota/usrquota/quota/uqnoenforce/qnoenforce
247 User disk quota accounting enabled, and limits (optionally) en‐
248 forced. Refer to xfs_quota(8) for further details.
249 gquota/grpquota/gqnoenforce
251 Group disk quota accounting enabled and limits (optionally) en‐
252 forced. Refer to xfs_quota(8) for further details.
253 pquota/prjquota/pqnoenforce
255 Project disk quota accounting enabled and limits (optionally)
256 enforced. Refer to xfs_quota(8) for further details.
257 sunit=value and swidth=value
259 Used to specify the stripe unit and width for a RAID device or a
260 stripe volume. "value" must be specified in 512-byte block
261 units. These options are only relevant to filesystems that were
262 created with non-zero data alignment parameters.
263 The sunit and swidth parameters specified must be compatible
265 with the existing filesystem alignment characteristics. In gen‐
266 eral, that means the only valid changes to sunit are increasing
267 it by a power-of-2 multiple. Valid swidth values are any integer
268 multiple of a valid sunit value.
269 Typically the only time these mount options are necessary if af‐
271 ter an underlying RAID device has had it's geometry modified,
272 such as adding a new disk to a RAID5 lun and reshaping it.
273 swalloc
275 Data allocations will be rounded up to stripe width boundaries
276 when the current end of file is being extended and the file size
277 is larger than the stripe width size.
278 wsync When specified, all filesystem namespace operations are executed
280 synchronously. This ensures that when the namespace operation
281 (create, unlink, etc) completes, the change to the namespace is
282 on stable storage. This is useful in HA setups where failover
283 must not result in clients seeing inconsistent namespace presen‐
284 tation during or after a failover event.
285
287 The following mount options have been removed from the kernel, and will
288 yield mount failures if specified. Mount options are deprecated for a
289 significant period time prior to removal.
290 Name Removed
292 ---- -------
293 delaylog/nodelaylog v4.0
294 ihashsize v4.0
295 irixsgid v4.0
296 osyncisdsync/osyncisosync v4.0
297 barrier/nobarrier v4.19
298
300 The XFS filesystem supports setting the following file attributes on
301 Linux systems using the chattr(1) utility:
302 a - append only
304 A - no atime updates
306 d - no dump
308 i - immutable
310 S - synchronous updates
312 For descriptions of these attribute flags, please refer to the
314 chattr(1) man page.
315
317 chattr(1), xfsctl(3), mount(8), mkfs.xfs(8), xfs_info(8), xfs_admin(8),
318 xfsdump(8), xfsrestore(8).
319 xfs(5)