1xfs(5)                        File Formats Manual                       xfs(5)
2
3
4

NAME

6       xfs  - layout, mount options, and supported file attributes for the XFS
7       filesystem
8

DESCRIPTION

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)
13       options,  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
19       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
34       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
41       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
48       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
56       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

OPERATIONS

66       Some  functionality  specific  to  the  XFS filesystem is accessible to
67       applications through the  xfsctl(3)  and  by-handle  (see  open_by_han‐
68       dle(3)) interfaces.
69

MOUNT OPTIONS

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
75       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
81              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
85              allocsize value turns off the dynamic behavior.
86
87       attr2|noattr2
88              The options enable/disable an "opportunistic" improvement to  be
89              made  in  the way inline extended attributes are stored on-disk.
90              When the new form is used for  the  first  time  when  attr2  is
91              selected  (either  when setting or removing extended attributes)
92              the on-disk superblock feature bit  field  will  be  updated  to
93              reflect this format being in use.
94
95              The  default  behavior  is determined by the on-disk feature bit
96              indicating that attr2 behavior is active. If either mount option
97              it  set,  then that becomes the new default used by the filesys‐
98              tem.
99
100              CRC enabled filesystems always use the attr2 format, and so will
101              reject the noattr2 mount option if it is set.
102
103       discard|nodiscard
104              Enable/disable  the  issuing of commands to let the block device
105              reclaim space freed by the filesystem.  This is useful  for  SSD
106              devices, thinly provisioned LUNs and virtual machine images, but
107              may have a performance impact.
108
109              Note: It is currently recommended that you use the fstrim appli‐
110              cation  to  discard  unused blocks rather than the discard mount
111              option because the performance impact of this  option  is  quite
112              severe.  For this reason, nodiscard is the default.
113
114       grpid|bsdgroups|nogrpid|sysvgroups
115              These  options  define  what group ID a newly created file gets.
116              When grpid is set, it takes the group ID  of  the  directory  in
117              which it is created; otherwise it takes the fsgid of the current
118              process, unless the directory has the setgid bit set,  in  which
119              case  it  takes the gid from the parent directory, and also gets
120              the setgid bit set if it is a directory itself.
121
122       filestreams
123              Make the data allocator  use  the  filestreams  allocation  mode
124              across  the  entire  filesystem  rather than just on directories
125              configured to use it.
126
127       ikeep|noikeep
128              When ikeep is specified, XFS does not delete empty  inode  clus‐
129              ters  and keeps them around on disk.  When noikeep is specified,
130              empty inode clusters  are  returned  to  the  free  space  pool.
131              noikeep is the default.
132
133       inode32|inode64
134              When  inode32  is  specified, it indicates that XFS limits inode
135              creation to locations which will not  result  in  inode  numbers
136              with more than 32 bits of significance.
137
138              When  inode64  is specified, it indicates that XFS is allowed to
139              create inodes at any location in the filesystem, including those
140              which  will  result in inode numbers occupying more than 32 bits
141              of significance.
142
143              inode32 is provided for backwards compatibility with older  sys‐
144              tems  and  applications, since 64 bits inode numbers might cause
145              problems for some applications that cannot  handle  large  inode
146              numbers.   If  applications are in use which do not handle inode
147              numbers bigger than 32 bits, the inode32 option should be speci‐
148              fied.
149
150              For kernel v3.7 and later, inode64 is the default.
151
152       largeio|nolargeio
153              If "nolargeio" is specified, the optimal I/O reported in st_blk‐
154              size by stat(2) will be as  small  as  possible  to  allow  user
155              applications  to  avoid inefficient read/modify/write I/O.  This
156              is typically the page size of the machine, as this is the granu‐
157              larity of the page cache.
158
159              If  "largeio"  specified,  a  filesystem that was created with a
160              "swidth" specified will return the "swidth" value (in bytes)  in
161              st_blksize. If the filesystem does not have a "swidth" specified
162              but does specify an "allocsize" then "allocsize" (in bytes) will
163              be  returned  instead.  Otherwise the behavior is the same as if
164              "nolargeio" was specified.  nolargeio is the default.
165
166       logbufs=value
167              Set the number of in-memory log buffers.   Valid  numbers  range
168              from 2–8 inclusive.
169
170              The default value is 8 buffers.
171
172              If  the  memory  cost of 8 log buffers is too high on small sys‐
173              tems, then it may be reduced at  some  cost  to  performance  on
174              metadata intensive workloads. The logbsize option below controls
175              the size of each buffer and so is also relevant to this case.
176
177       logbsize=value
178              Set the size of each in-memory log  buffer.   The  size  may  be
179              specified  in  bytes,  or  in kibibytes (KiB) with a "k" suffix.
180              Valid  sizes  for  version  1  and  version  2  logs  are  16384
181              (value=16k)  and  32768  (value=32k).  Valid sizes for version 2
182              logs also include 65536  (value=64k),  131072  (value=128k)  and
183              262144 (value=256k). The logbsize must be an integer multiple of
184              the log stripe unit configured at mkfs time.
185
186              The default value for version 1 logs is 32768, while the default
187              value for version 2 logs is max(32768, log_sunit).
188
189       logdev=device and rtdev=device
190              Use  an external log (metadata journal) and/or real-time device.
191              An XFS filesystem has up to three parts: a data section,  a  log
192              section,  and  a  real-time  section.   The real-time section is
193              optional, and the log section can be separate from the data sec‐
194              tion or contained within it.
195
196       noalign
197              Data  allocations will not be aligned at stripe unit boundaries.
198              This is only relevant to filesystems created with non-zero  data
199              alignment parameters (sunit, swidth) by mkfs.
200
201       norecovery
202              The filesystem will be mounted without running log recovery.  If
203              the filesystem was not cleanly unmounted, it  is  likely  to  be
204              inconsistent  when  mounted in "norecovery" mode.  Some files or
205              directories may not be accessible because of this.   Filesystems
206              mounted "norecovery" must be mounted read-only or the mount will
207              fail.
208
209       nouuid Don't check for double mounted file systems using the file  sys‐
210              tem  uuid.   This  is  useful to mount LVM snapshot volumes, and
211              often used in combination with "norecovery" for  mounting  read-
212              only snapshots.
213
214       noquota
215              Forcibly  turns  off all quota accounting and enforcement within
216              the filesystem.
217
218       uquota/usrquota/quota/uqnoenforce/qnoenforce
219              User disk quota  accounting  enabled,  and  limits  (optionally)
220              enforced.  Refer to xfs_quota(8) for further details.
221
222       gquota/grpquota/gqnoenforce
223              Group  disk  quota  accounting  enabled  and limits (optionally)
224              enforced.  Refer to xfs_quota(8) for further details.
225
226       pquota/prjquota/pqnoenforce
227              Project disk quota accounting enabled  and  limits  (optionally)
228              enforced.  Refer to xfs_quota(8) for further details.
229
230       sunit=value and swidth=value
231              Used to specify the stripe unit and width for a RAID device or a
232              stripe volume.  "value" must  be  specified  in  512-byte  block
233              units.  These options are only relevant to filesystems that were
234              created with non-zero data alignment parameters.
235
236              The sunit and swidth parameters  specified  must  be  compatible
237              with the existing filesystem alignment characteristics.  In gen‐
238              eral, that means the only valid changes to sunit are  increasing
239              it by a power-of-2 multiple. Valid swidth values are any integer
240              multiple of a valid sunit value.
241
242              Typically the only time these mount  options  are  necessary  if
243              after  an underlying RAID device has had it's geometry modified,
244              such as adding a new disk to a RAID5 lun and reshaping it.
245
246       swalloc
247              Data allocations will be rounded up to stripe  width  boundaries
248              when the current end of file is being extended and the file size
249              is larger than the stripe width size.
250
251       wsync  When specified, all filesystem namespace operations are executed
252              synchronously.  This  ensures  that when the namespace operation
253              (create, unlink, etc) completes, the change to the namespace  is
254              on  stable  storage.  This is useful in HA setups where failover
255              must not result in clients seeing inconsistent namespace presen‐
256              tation during or after a failover event.
257

REMOVED MOUNT OPTIONS

259       The following mount options have been removed from the kernel, and will
260       yield mount failures if specified.  Mount options are deprecated for  a
261       significant period time prior to removal.
262
263       Name                        Removed
264       ----                        -------
265       delaylog/nodelaylog         v4.0
266       ihashsize                   v4.0
267       irixsgid                    v4.0
268       osyncisdsync/osyncisosync   v4.0
269       barrier/nobarrier           v4.19
270

FILE ATTRIBUTES

272       The  XFS  filesystem  supports setting the following file attributes on
273       Linux systems using the chattr(1) utility:
274
275       a - append only
276
277       A - no atime updates
278
279       d - no dump
280
281       i - immutable
282
283       S - synchronous updates
284
285       For  descriptions  of  these  attribute  flags,  please  refer  to  the
286       chattr(1) man page.
287

SEE ALSO

289       chattr(1), xfsctl(3), mount(8), mkfs.xfs(8), xfs_info(8), xfs_admin(8),
290       xfsdump(8), xfsrestore(8).
291
292
293
294                                                                        xfs(5)
Impressum