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