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

FILE ATTRIBUTES

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

SEE ALSO

284       chattr(1), xfsctl(3), mount(8), mkfs.xfs(8), xfs_info(8), xfs_admin(8),
285       xfsdump(8), xfsrestore(8).
286
287
288
289                                                                        xfs(5)
Impressum