An XFS filesystem can reside on a regular disk partition or on a  logi-
       cal volume.  An XFS filesystem has up to three parts: a data section, a
       log section, and a realtime section.   Using  the  default  mkfs.xfs(8)
       options,  the realtime section is absent, and the log area is contained
       within the data section.  The log section can be either  separate  from
       the  data  section or contained within it.  The filesystem sections are
       divided into a certain number of blocks, whose  size  is  specified  at
       mkfs.xfs(8) time with the -b option.

       The data section contains all the filesystem metadata (inodes, directo-
       ries, indirect blocks) as well as the user file data for ordinary (non-
       realtime)  files  and  the  log area if the log is internal to the data
       section.  The data section is  divided  into  a  number  of  allocation
       groups.   The  number  and  size of the allocation groups are chosen by
       mkfs.xfs(8) so that there is normally a  small  number  of  equal-sized
       groups.   The number of allocation groups controls the amount of paral-
       lelism 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  allo-
       cation  groups  are  added (of the original size) when xfs_growfs(8) is

       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  writ-
       ten  sequentially  during  normal operation and read only during mount.
       When mounting a filesystem after a crash, the log is read  to  complete
       operations that were in progress at the time of the crash.

       The  realtime  section  is  used  to  store the data of realtime files.
       These files had an attribute bit set through xfsctl(3) after file  cre-
       ation,  before  any data was written to the file.  The realtime section
       is divided into a  number  of  extents  of  fixed  size  (specified  at
       mkfs.xfs(8)  time).   Each  file  in the realtime section has an extent
       size that is a multiple of the realtime section extent size.

       Each allocation group contains several data structures.  The first sec-
       tor  contains  the  superblock.  For allocation groups after the first,
       the superblock is just a copy and is  not  updated  after  mkfs.xfs(8).
       The  next three sectors contain information for block and inode alloca-
       tion within the allocation group.  Also contained within  each  alloca-
       tion  group are data structures to locate free blocks and inodes; these
       are located through the header structures.

       Each XFS filesystem is  labeled  with  a  Universal  Unique  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  dd(1) or other block-by-block copying programs to

              Sets  the buffered I/O end-of-file preallocation size when doing
              delayed allocation writeout. Valid values for  this  option  are
              page size (typically 4KiB) through to 1GiB, inclusive, in power-
              of-2 increments.

              The default behavior is for  dynamic  end-of-file  preallocation
              size,  which uses a set of heuristics to optimise the prealloca-
              tion size based on the current allocation  patterns  within  the
              file  and  the  access  patterns to the file. Specifying a fixed
              allocsize value turns off the dynamic behavior.

              The options enable/disable an "opportunistic" improvement to  be
              made  in  the way inline extended attributes are stored on-disk.
              When the new form is used for  the  first  time  when  attr2  is
              selected  (either  when setting or removing extended attributes)
              the on-disk superblock feature bit  field  will  be  updated  to
              reflect this format being in use.

              The  default  behavior  is determined by the on-disk feature bit
              indicating that attr2 behavior is active. If either mount option
              it  set,  then that becomes the new default used by the filesys-

              CRC enabled filesystems always use the attr2 format, and so will
              reject the noattr2 mount option if it is set.

              Enables/disables  the  use  of  block  layer  write barriers for
              writes into the journal and for data integrity operations.  This
              allows  for drive level write caching to be enabled, for devices
              that support write barriers.

              Barriers are enabled by default.

              Enable/disable the issuing of commands to let the  block  device
              reclaim  space  freed by the filesystem.  This is useful for SSD
              devices, thinly provisioned LUNs and virtual machine images, but
              may have a performance impact.

              Note: It is currently recommended that you use the fstrim appli-
              cation to discard unused blocks rather than  the  discard  mount
              option  because  the  performance impact of this option is quite
              severe.  For this reason, nodiscard is the default.

              These options define what group ID a newly  created  file  gets.
              When  grpid  is  set,  it takes the group ID of the directory in
              which it is created; otherwise it takes the fsgid of the current

              When inode32 is specified, it indicates that  XFS  limits  inode
              creation  to  locations  which  will not result in inode numbers
              with more than 32 bits of significance.

              When inode64 is specified, it indicates that XFS is  allowed  to
              create inodes at any location in the filesystem, including those
              which will result in inode numbers occupying more than  32  bits
              of significance.

              inode32  is provided for backwards compatibility with older sys-
              tems and applications, since 64 bits inode numbers  might  cause
              problems  for  some  applications that cannot handle large inode
              numbers.  If applications are in use which do not  handle  inode
              numbers bigger than 32 bits, the inode32 option should be speci-

              For kernel v3.7 and later, inode64 is the default.

              If "nolargeio" is specified, the optimal I/O reported in st_blk-
              size  by  stat(2)  will  be  as  small as possible to allow user
              applications to avoid inefficient read/modify/write  I/O.   This
              is typically the page size of the machine, as this is the granu-
              larity of the page cache.

              If "largeio" specified, a filesystem that  was  created  with  a
              "swidth"  specified will return the "swidth" value (in bytes) in
              st_blksize. If the filesystem does not have a "swidth" specified
              but does specify an "allocsize" then "allocsize" (in bytes) will
              be returned instead. Otherwise the behavior is the  same  as  if
              "nolargeio" was specified.  nolargeio is the default.

              Set  the  number  of in-memory log buffers.  Valid numbers range
              from 2-8 inclusive.

              The default value is 8 buffers.

              If the memory cost of 8 log buffers is too high  on  small  sys-
              tems,  then  it  may  be  reduced at some cost to performance on
              metadata intensive workloads. The logbsize option below controls
              the size of each buffer and so is also relevant to this case.

              Set  the  size  of  each  in-memory log buffer.  The size may be
              specified in bytes, or in kibibytes (KiB)  with  a  "k"  suffix.
              Valid  sizes  for  version  1  and  version  2  logs  are  16384
              (value=16k) and 32768 (value=32k).  Valid sizes  for  version  2
              logs  also  include  65536  (value=64k), 131072 (value=128k) and
              262144 (value=256k). The logbsize must be an integer multiple of
              This  is only relevant to filesystems created with non-zero data
              alignment parameters (sunit, swidth) by mkfs.

              The filesystem will be mounted without running log recovery.  If
              the  filesystem  was  not  cleanly unmounted, it is likely to be
              inconsistent when mounted in "norecovery" mode.  Some  files  or
              directories  may not be accessible because of this.  Filesystems
              mounted "norecovery" must be mounted read-only or the mount will

       nouuid Don't  check for double mounted file systems using the file sys-
              tem uuid.  This is useful to mount  LVM  snapshot  volumes,  and
              often  used  in combination with "norecovery" for mounting read-
              only snapshots.

              Forcibly turns off all quota accounting and  enforcement  within
              the filesystem.

              User  disk  quota  accounting  enabled,  and limits (optionally)
              enforced.  Refer to xfs_quota(8) for further details.

              Group disk quota  accounting  enabled  and  limits  (optionally)
              enforced.  Refer to xfs_quota(8) for further details.

              Project  disk  quota  accounting enabled and limits (optionally)
              enforced.  Refer to xfs_quota(8) for further details.

       sunit=value and swidth=value
              Used to specify the stripe unit and width for a RAID device or a
              stripe  volume.   "value"  must  be  specified in 512-byte block
              units. These options are only relevant to filesystems that  were
              created with non-zero data alignment parameters.

              The  sunit  and  swidth  parameters specified must be compatible
              with the existing filesystem alignment characteristics.  In gen-
              eral,  that means the only valid changes to sunit are increasing
              it by a power-of-2 multiple. Valid swidth values are any integer
              multiple of a valid sunit value.

              Typically  the  only  time  these mount options are necessary if
              after an underlying RAID device has had it's geometry  modified,
              such as adding a new disk to a RAID5 lun and reshaping it.

              Data  allocations  will be rounded up to stripe width boundaries
              when the current end of file is being extended and the file size
              is larger than the stripe width size.

       A - no atime updates

       d - no dump

       i - immutable

       S - synchronous updates

       For  descriptions  of  these  attribute  flags,  please  refer  to  the
       chattr(1) man page.


       chattr(1), xfsctl(3), mount(8), mkfs.xfs(8), xfs_info(8), xfs_admin(8),
       xfsdump(8), xfsrestore(8).

Subscribe to us on YouTube