GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing docs.kernel.org — The SGI XFS Filesystem — The Linux Kernel documentation The SGI XFS Filesystem¶XFS is a high performance journaling filesystem which originated on the SGI IRIX platform. It is completely multi-threaded, can support large files and large filesystems, extended attributes, variable block sizes, is extent based, and makes extensive use of Btrees (directories, extents, free space) to aid both performance and scalability. Refer to the documentation at https://xfs.wiki.kernel.org/ for further details. This implementation is on-disk compatible with the IRIX version of XFS. Mount Options¶When mounting an XFS filesystem, the following options are accepted.
Deprecation of V4 Format¶The V4 filesystem format lacks certain features that are supported by the V5 format, such as metadata checksumming, strengthened metadata verification, and the ability to store timestamps past the year 2038. Because of this, the V4 format is deprecated. All users should upgrade by backing up their files, reformatting, and restoring from the backup. Administrators and users can detect a V4 filesystem by running xfs_info against a filesystem mountpoint and checking for a string containing “crc=”. If no such string is found, please upgrade xfsprogs to the latest version and try again. The deprecation will take place in two parts. Support for mounting V4 filesystems can now be disabled at kernel build time via Kconfig option. These options were changed to default to no in September 2025. In September 2030, support will be removed from the codebase entirely. Note: Distributors may choose to withdraw V4 format support earlier than the dates listed above. Deprecated Mount Options¶
Removed Mount Options¶
sysctls¶The following sysctls are available for the XFS filesystem:
Deprecated Sysctls¶None currently. Removed Sysctls¶
Error handling¶XFS can act differently according to the type of error found during its operation. The implementation introduces the following concepts to the error handler:
The filesystem behavior during an error can be set via The action taken by the filesystem when the error is propagated is context dependent - it may cause a shut down in the case of an unrecoverable error, it may be reported back to userspace, or it may even be ignored because there’s nothing useful we can with the error or anyone we can report it to (e.g. during unmount). The configuration files are organized into the following hierarchy for each mounted filesystem:
Each filesystem has “global” error configuration options defined in their top level directory:
Each filesystem has specific error class handlers that define the error propagation behaviour for specific errors. There is also a “default” error handler defined, which defines the behaviour for all errors that don’t have specific handlers defined. Where multiple retry constraints are configured for a single error, the first retry configuration that expires will cause the error to be propagated. The handler configurations are found in the directory:
Note: The default behaviour for a specific error handler is dependent on both the class and error context. For example, the default values for “metadata/ENODEV” are “0” rather than “-1” so that this error handler defaults to “fail immediately” behaviour. This is done because ENODEV is a fatal, unrecoverable error no matter how many times the metadata IO is retried. Workqueue Concurrency¶XFS uses kernel workqueues to parallelize metadata update processes. This enables it to take advantage of storage hardware that can service many IO operations simultaneously. This interface exposes internal implementation details of XFS, and as such is explicitly not part of any userspace API/ABI guarantee the kernel may give userspace. These are undocumented features of the generic workqueue implementation XFS uses for concurrency, and they are provided here purely for diagnostic and tuning purposes and may change at any time in the future. The control knobs for a filesystem’s workqueues are organized by task at hand and the short name of the data device. They all can be found in:
For example, the knobs for the quotacheck workqueue for /dev/nvme0n1 would be found in /sys/bus/workqueue/devices/xfs_iwalk-1111!nvme0n1/. The interesting knobs for XFS workqueues are as follows:
Zoned Filesystems¶For zoned file systems, the following attributes are exposed in:
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |