Editing XFS (section)

==Features==

===Capacity===
XFS is a 64-bit file system<ref>{{cite web |url=http://oss.sgi.com/projects/xfs/index.html |title=XFS Overview |publisher=Silicon Graphics International Corp |date=2013-07-02 |access-date=2013-07-02 |url-status=dead |archive-url=https://web.archive.org/web/20130606024601/http://oss.sgi.com/projects/xfs/index.html |archive-date=2013-06-06 }}</ref> and supports a maximum file system size of 8 [[exbibyte]]s minus one byte (2<sup>63</sup>&nbsp;− 1 bytes), but limitations imposed by the host operating system can decrease this limit. [[32-bit]] Linux systems limit the size of both the file and file system to 16 [[tebibyte]]s.

===Journaling===
{{Details|Journaling file system}}

In modern computing, journaling is a capability which ensures consistency of data in the file system, despite any power outages or system crash that may occur. XFS provides journaling for file system metadata, where file system updates are first written to a serial journal before the actual disk blocks are updated. The journal is a circular buffer of disk blocks that is not read in normal file system operation.

The XFS journal can be stored within the data section of the file system (as an internal log), or on a separate device to minimize disk contention.

In XFS, the journal primarily contains entries that describe the portions of the disk blocks changed by filesystem operations. Journal updates are performed asynchronously to avoid a decrease in performance speed.

In the event of a system crash, file system operations which occurred immediately prior to the crash can be reapplied and completed as recorded in the journal, which is how data stored in XFS file systems remain consistent. Recovery is performed automatically the first time the file system is mounted after the crash. The speed of recovery is independent of the size of the file system, instead depending on the amount of file system operations to be reapplied.

===Allocation groups===
XFS file systems are internally partitioned into ''allocation groups'', which are equally sized linear regions within the file system. [[Computer file|Files]] and directories can span allocation groups. Each allocation group manages its own [[inode]]s and free space separately, providing scalability and parallelism so multiple threads and processes can perform I/O operations on the same file system simultaneously.

This architecture helps to optimize parallel I/O performance on systems with multiple processors and/or cores, as metadata updates can also be parallelized. The internal partitioning provided by allocation groups can be especially beneficial when the file system spans multiple physical devices, allowing optimal usage of throughput of the underlying storage components.

===Striped allocation===
If an XFS file system is to be created on a striped [[redundant array of independent disks|RAID]] array, a ''[[Data striping|stripe]] unit'' can be specified when the file system is created. This maximizes throughput by ensuring that data allocations, inode allocations and the internal log (the journal) are aligned with the stripe unit.

===Extent-based allocation===
Blocks used in files stored on XFS file systems are managed with variable length [[extent (file systems)|extents]] where one extent describes one or more contiguous blocks. This can shorten the list of blocks considerably, compared to file systems that list all blocks used by a file individually.

Block-oriented file systems manage space allocation with one or more block-oriented bitmaps; in XFS, these structures are replaced with an extent oriented structure consisting of a pair of [[B+ tree]]s for each file system allocation group. One of the B+ trees is indexed by the length of the free extents, while the other is indexed by the starting block of the free extents. This dual indexing scheme allows for the highly efficient allocation of free extents for file system operations.

===Variable block sizes===
The file system block size represents the minimum allocation unit. XFS allows file systems to be created with block sizes ranging between 512&nbsp;bytes and 64&nbsp;KB, allowing the file system to be tuned for the expected degree of usage. When many small files are expected, a small block size would typically maximize capacity, but for a system dealing mainly with large files, a larger block size can provide a performance efficiency advantage.

===Delayed allocation===
{{Main|Delayed allocation}}

XFS makes use of [[lazy evaluation]] techniques for file allocation. When a file is written to the buffer cache, rather than allocating extents for the data, XFS simply reserves the appropriate number of file system blocks for the data held in memory. The actual block allocation occurs only when the data is finally flushed to disk. This improves the chance that the file will be written in a contiguous group of blocks, reducing [[file system fragmentation|fragmentation]] problems and increasing performance.

===Sparse files===
XFS provides a 64-bit sparse address space for each file, which allows both for very large file sizes, and for "holes" within files in which no disk space is allocated. As the file system uses an extent map for each file, the file allocation map size is kept small. Where the size of the allocation map is too large for it to be stored within the inode, the map is moved into a B+ tree which allows for rapid access to data anywhere in the 64-bit address space provided for the file.

===Extended attributes===
XFS provides multiple data streams for files; this is made possible by its implementation of [[extended file attributes|extended attributes]]. These allow the storage of a number of name/value pairs attached to a file. Names are nul-terminated printable character strings which are up to 256&nbsp;bytes in length, while their associated values can contain up to 64&nbsp;[[kilobyte|KB]] of binary data.

They are further subdivided into two namespaces: <code>root</code> and <code>user</code>. Extended attributes stored in the root namespace can be modified only by the superuser, while attributes in the user namespace can be modified by any user with permission to write to the file.

Extended attributes can be attached to any kind of XFS inode, including symbolic links, device nodes, directories, etc. The <code>attr</code> utility can be used to manipulate extended attributes from the command line, and the <code>xfsdump</code> and <code>xfsrestore</code> utilities are aware of extended attributes, and will back up and restore their contents. Many other backup systems do not support working with extended attributes.

===Direct I/O===
For applications requiring high throughput to disk, XFS provides a direct I/O implementation that allows non-cached I/O operations to be applied directly to the userspace. Data is transferred between the buffer of the application and the disk using [[Direct memory access|DMA]], which allows access to the full I/O bandwidth of the underlying disk devices.

===Snapshots===
XFS does not yet<ref>{{cite web|url=https://lwn.net/Articles/638546/|title=XFS: There and back ... and there again? [LWN.net]|website=lwn.net|access-date=2016-10-27|archive-url=https://web.archive.org/web/20161027192827/https://lwn.net/Articles/638546/|archive-date=2016-10-27|url-status=live}}</ref> provide direct support for snapshots, as it currently expects the snapshot process to be implemented by the volume manager. Taking a snapshot of an XFS filesystem involves temporarily halting I/O to the filesystem using the <code>xfs_freeze</code> utility, having the volume manager perform the actual snapshot, and then resuming I/O to continue with normal operations. The snapshot can then be mounted read-only for backup purposes.

Releases of XFS in IRIX incorporated an integrated volume manager called XLV. This volume manager has not been ported to Linux, and XFS works with standard [[Logical Volume Manager (Linux)|LVM]] in Linux systems instead.

In recent Linux kernels, the <code>xfs_freeze</code> functionality is implemented in the VFS layer, and is executed automatically when the Volume Manager's snapshot functionality is invoked. This was once a valuable advantage as the [[ext3]] file system could not be suspended<ref>{{cite web|url=http://www.linuxquestions.org/questions/programming-9/how-to-freeze-ext3-file-system-229937/|title=How to freeze ext3 file system|website=www.linuxquestions.org|access-date=2011-08-24|archive-url=https://web.archive.org/web/20110428190523/http://www.linuxquestions.org/questions/programming-9/how-to-freeze-ext3-file-system-229937/|archive-date=2011-04-28|url-status=live}}</ref> and the volume manager was unable to create a consistent "hot" snapshot to back up a heavily busy database.<ref>{{cite web|url=http://www.linuxquestions.org/questions/linux-server-73/lvm-snapshots-how-to-use-622084/|title=LVM snapshots: How to use?|website=www.linuxquestions.org|access-date=2010-04-17|archive-url=https://web.archive.org/web/20110117044017/http://www.linuxquestions.org/questions/linux-server-73/lvm-snapshots-how-to-use-622084/|archive-date=2011-01-17|url-status=live}}</ref> Fortunately this is no longer the case. Since Linux 2.6.29, the file systems ext3, [[ext4]], [[GFS2]] and [[JFS (file system)|JFS]] have the freeze feature as well.<ref>{{cite web|url=https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c4be0c1dc4cdc37b175579be1460f15ac6495e9a|title=kernel/git/torvalds/linux.git - Linux kernel source tree|website=git.kernel.org}}</ref>

===Online defragmentation===
Although the extent-based nature of XFS and the delayed allocation strategy it uses significantly improves the file system's resistance to fragmentation problems, XFS provides a filesystem [[defragmentation]] utility (<code>xfs_fsr</code>, short for XFS filesystem reorganizer) that can defragment the files on a mounted and active XFS filesystem.<ref>[http://bitubique.com/content/defragment-xfs-file-system Bitubique.com] {{webarchive |url=https://web.archive.org/web/20090401211105/http://bitubique.com/content/defragment-xfs-file-system |date=April 1, 2009 }}</ref>

===Online growth===
XFS provides the <code>xfs_growfs</code> utility to perform online expansion of XFS file systems. XFS filesystems can be grown so long as there is remaining unallocated space on the device holding the filesystem. This feature is typically used in conjunction with volume management, as otherwise the [[Disk partitioning|partition]] holding the filesystem will need enlarging separately.

===IRIX-only features===

====DMAPI====
XFS implemented the [[DMAPI]] interface to support [[Hierarchical Storage Management]] in IRIX. As of October 2010, the Linux implementation of XFS supported the required on-disk metadata for DMAPI implementation, but the kernel support was reportedly not usable. For some time, SGI hosted a kernel tree which included the DMAPI hooks, but this support has not been adequately maintained, although kernel developers have stated an intention to bring this support up to date.<ref>{{Cite mailing list |url= http://oss.sgi.com/archives/xfs/2010-10/msg00025.html |title= Re: Linux and DMAPI |author= Christoph Hellwig |date= October 3, 2010 |mailing-list= XFS mailing list |publisher= SGI |access-date= November 6, 2011 |archive-url= https://web.archive.org/web/20110927020239/http://oss.sgi.com/archives/xfs/2010-10/msg00025.html |archive-date= September 27, 2011 |url-status= dead }}</ref>

====Guaranteed-rate I/O====
The XFS guaranteed-rate I/O system provides an API that allows applications to reserve bandwidth to the filesystem. XFS dynamically calculates the performance available from the underlying storage devices, and will reserve bandwidth sufficient to meet the requested performance for a specified time. This is a feature unique to the XFS file system. Guaranteed rates can be "hard" or "soft", representing a trade off between reliability and performance; however, XFS will only allow "hard" guarantees if the underlying storage subsystem supports it. This facility is used mostly for real-time applications, such as video streaming.

Guaranteed-rate I/O was only supported under [[IRIX]], and required special hardware for that purpose.<ref>{{Cite mailing list |url= http://oss.sgi.com/archives/xfs/2012-07/msg00432.html |title= Re: Re: realtime section bugs still around |author= Dave Chinner |date= July 30, 2012 |mailing-list= XFS mailing list |publisher= SGI |access-date= April 13, 2014 |archive-url= https://web.archive.org/web/20140414085238/http://oss.sgi.com/archives/xfs/2012-07/msg00432.html |archive-date= April 14, 2014 |url-status= live }}</ref>