XFS

From Wikipedia, the free encyclopedia

You have new messages (last change).
This article is about the XFS file system. For font server, see X Font Server. For the Microsoft Windows API for financial services hardware, see CEN/XFS.
XFS
Developer Silicon Graphics Inc.
Full name XFS
Introduced 1994 (IRIX v5.3)
Partition identifier
Structures
Directory contents B+ trees
File allocation extent based
Bad blocks
Limits
Max file size 8 exabytes
Max number of files
Max filename size 255 bytes
Max volume size 8 exabytes
Allowed characters in filenames All bytes except NUL
Features
Dates recorded Yes
Date range
Forks Yes (called extended attributes)
Attributes
File system permissions Yes
Transparent compression No
Transparent encryption No (provided at the block device level)
Supported operating systems IRIX, Linux, FreeBSD

XFS is a high-performance journaling file system created by Silicon Graphics for their IRIX operating system.

Contents

[edit] History

XFS is the oldest journaling file system available for UNIX systems, and has a mature, stable and well-debugged codebase. Development of XFS was started by Silicon Graphics, in 1993, with first deployment being seen on IRIX 5.3 in 1994. The filesystem was released under the GNU General Public License in May 2000, and ported to Linux, with the first distribution support appearing in 2001/2002. It is available in almost all Linux distributions today.

XFS has been merged into the mainline Linux 2.4 (as of 2.4.25, when Marcelo Tosatti judged it stable enough) and 2.6 kernels, making it almost universally available on Linux systems. Installation programs for the SuSE, Gentoo, Mandriva, Slackware, Kate OS, Zenwalk, Ubuntu and Debian Linux distributions all offer XFS as a choice of filesystem. FreeBSD gained read-only support for XFS in December 2005 and in June 2006 experimental write support was introduced to FreeBSD-7.0-CURRENT.

[edit] Specifications

[edit] Capacity

XFS is a 64-bit journaling file system with guaranteed file system consistency. It supports a maximum file system size of 8 exabytes, though this is subject to block limits imposed by the host operating system. On 32-bit Linux systems, this limits the file and file system sizes to 16 terabytes.

[edit] Journaling

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 never read in normal filesystem operation. It can be stored within the data section of the filesystem (an internal log), or on a separate device to minimise disk contention. On XFS the journal contains 'logical' entries that describe at a high level what operations are being performed, as opposed to other filesystems with 'physical' journals that store a copy of the blocks modified during each transaction. Journal updates are performed asynchronously to avoid incurring a performance penalty. In the event of a system crash, operations immediately prior to the crash can be redone using data in the journal, which allows XFS to guarantee file system consistency. Recovery is performed automatically at file system mount time, and the recovery speed is independent of the size of the file system. Where recently modified data has not been flushed to disk before a system crash, XFS ensures that any unwritten data blocks are zeroed on reboot, obviating any possible security issues arising from residual data.

[edit] Allocation groups

XFS filesystems are internally partitioned into allocation groups, which are equally sized linear regions within the file system. Files and directories can span allocation groups. Each allocation group manages its own inodes and free space separately, providing scalability and parallelism — multiple threads and processes can perform I/O operations on the same filesystem simultaneously. This architecture helps to optimise parallel I/O performance on multiprocessor or multicore systems, as metadata updates are also parellelisable. The internal partitioning provided by allocation groups can be especially beneficial when the file systems spans multiple physical devices, allowing for optimal usage of bandwidth of the underlying storage components.

[edit] Striped allocation

If an XFS filesystem is to be created on a RAID array, a stripe unit can be specified when the file system is created. This maximises throughput by ensuring that data allocations, inode allocations and the internal log (journal) are aligned with the stripe unit.

[edit] Extent based allocation

Blocks used in files stored on XFS filesystems are managed with variable length extents where one extent describes one or more contiguous blocks. This can shorten the list considerably compared to file systems that list all blocks used by a file individually. Also many 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+ trees for each filesystem allocation group (AG). 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 highly efficient location of free extents for file system operations.

[edit] 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 bytes and 64 kibibytes, allowing the file system to be tuned for the expected use. Where a large amount of small files is to be expected, a small block size would typically be used to maximize capacity, but for a system dealing mainly with large files, a larger block size can provide a performance advantage.

[edit] Delayed allocation

Main article: 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 fragmentation problems and increasing performance.

[edit] 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 for 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.

[edit] Extended attributes

XFS provides multiple data streams for files through its implementation of extended attributes. These allow the storage of a number of name/value pairs attached to a file. Names are null terminated printable character strings of up to 256 bytes in length, while their associated values can contain up to 64Kb of binary data. They are further subdivided into two namespaces, root and user. 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 attr program can be used to manipulate extended attributes from the command line, and the xfsdump and xfsrestore utilities are aware of them and will back up and restore their contents. Most other backup systems are not extended attribute aware.

[edit] Direct I/O

For applications requiring high throughput to disk, XFS provides a direct I/O implementation that allows non-cached I/O directly to userspace. Data is transferred between the application's buffer and the disk using DMA, which allows access to the full I/O bandwidth of the underlying disk devices.

[edit] Guaranteed rate I/O

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

[edit] DMAPI

XFS implents the DMAPI interface to support Hierarchical Storage Management. While this functionality has been ported to the Linux implementations of XFS, it is not yet a part of the mainline Linux kernel source.

[edit] Snapshots

XFS does not provide direct support for snapshots, as it expects the snapshot process to be implemented by the volume manager. Taking a snapshot of an XFS filesystem involves freezing I/O to the filesystem using the xfs_freeze utility, having the volume manager perform the actual snapshot, and then unfreezing I/O to resume normal operations. The snapshot can then be mounted read-only for backup purposes. XFS releases on IRIX incorporated an integrated volume manager called XLV. This volume manager has not been ported to Linux. In recent Linux kernels, the xfs_freeze functionality is implemented in the VFS layer, and happens automatically when the Volume Manager's snapshot functionality is invoked.

[edit] Online defragmentation

Although the extent based nature of XFS and the delayed allocation strategy it used significantly improves the file system's resistance to fragmentation problems, XFS provides a filesystem defragmentation utility (xfs_fsr, short for XFS filesystem repacker) that can defragment a mounted and active XFS filesystem. Note that xfs_fsr is usually part of xfsdump package, not xfsprogs.

[edit] Online resizing

XFS provides the xfs_growfs utility to perform online resizing of XFS file systems. XFS filesystems can be grown provided there is remaining unallocated space on the device holding the filesystem. This feature is typically used in conjunction with volume management, as otherwise the partition holding the filesystem will need enlarging separately.

[edit] Native backup/restore utilities

XFS provides the xfsdump and xfsrestore utilities to aid in backup of data held on XFS file systems. The xfsdump utility backs up an XFS filesystem in inode order, and in contrast to traditional UNIX file systems which must be unmounted before dumping to guarantee a consistent dump image, XFS file systems can be dumped while the file system is in use. XFS dumps and restores are also resumable, and can be interrupted without difficulty. The multi-threaded operation of xfsdump provides high performance of backup operations by splitting the dump into multiple streams, which can be sent to different dump destinations. The multi stream capabilities have not been fully ported to Linux yet, however.

[edit] Disadvantages

  • Recovering deleted files from an XFS filesystem is almost impossible (though this can be an advantage, too)
  • On the Linux XFS implementations, compatibility issues between different architectures exist due to journaling-optimization. This can be solved by running xfs_repair (to clean the journal) before mounting the file system on a different architecture.
  • XFS journals metadata. This means that if you pull the power cord out of your computer, when you turn it on again, XFS will be in a consistent state (i.e. you will see your directories, and be able to list the files they contain). This is an advantage compared to not being able to see anything. However, you will probably have lost the data from files that were open at the time of pulling out the power cord because XFS does not journal data changes. SGI (August 28, 2006). XFS FAQ. XFS is not alone here — some other file systems (such as JFS) also journal metadata changes and not data changes because it's a good strategy when mediating between speed requirements and safety.
  • XFS takes a liberal reading of SuS when it comes to optimizing delayed allocation and the ordering of meta-data and data flush to disk. As a consequence, some operations that work with ext3 or ReiserFS in data=ordered mode have caused data corruption for several people: 
    echo "original data here" > data
echo "new data goes here" > data.new
mv data.new data
*crash*
    With the three commands run just before a crash or power loss, there is a chance the file will have random data or null characters. See this bug report in Ubuntu and this posting from a XFS developer on linux-xfs for opposing views on this issue.
  • Creation of directory entries (empty files, subdirectories, etc.) and especially deletion of entries are very slow metadata operations compared to other filesystems. See Filesystem performance tweaking with XFS on Linux for details.

[edit] See also

[edit] External links

Retrieved from "http://en.wikipedia.org../../../x/f/s/XFS_dd14.html"