XFS FAQ - Revision history

10.0.0.20: IRC switched from freenode to oftc

2022-08-17T09:28:00Z

IRC switched from freenode to oftc

← Older revision		Revision as of 09:28, 17 August 2022
Line 8:		Line 8:
	The SGI XFS project page http://oss.sgi.com/projects/xfs/ is the definitive reference. It contains pointers to whitepapers, books, articles, etc.		The SGI XFS project page http://oss.sgi.com/projects/xfs/ is the definitive reference. It contains pointers to whitepapers, books, articles, etc.

	You could also join the [[XFS_email_list_and_archives\|XFS mailing list]] or the '''<nowiki>#xfs</nowiki>''' IRC channel on ''irc.~~freenode~~.net''.		You could also join the [[XFS_email_list_and_archives\|XFS mailing list]] or the '''<nowiki>#xfs</nowiki>''' IRC channel on ''irc.oftc.net''.

	== Q: Where can I find documentation about ACLs? ==		== Q: Where can I find documentation about ACLs? ==

Sandeen: /* Q: Where can I find information about the internals of XFS? */

2018-07-30T22:32:12Z

Q: Where can I find information about the internals of XFS?

← Older revision		Revision as of 22:32, 30 July 2018
Line 20:		Line 20:
	An [http://oss.sgi.com/projects/xfs/training/ SGI XFS Training course] aimed at developers, triage and support staff, and serious users has been in development. Parts of the course are clearly still incomplete, but there is enough content to be useful to a broad range of users.		An [http://oss.sgi.com/projects/xfs/training/ SGI XFS Training course] aimed at developers, triage and support staff, and serious users has been in development. Parts of the course are clearly still incomplete, but there is enough content to be useful to a broad range of users.

	Barry Naujok ~~has documented~~ the [~~http~~://~~oss~~.~~sgi~~.~~com~~/~~projects~~/xfs/~~papers~~/xfs_filesystem_structure.pdf XFS ondisk format] which is a very useful reference.		Darrick has updated Barry Naujok's documentation of the [https://www.kernel.org/pub/linux/utils/fs/xfs/docs/xfs_filesystem_structure.pdf XFS ondisk format] which is a very useful reference.

	== Q: What partition type should I use for XFS on Linux? ==		== Q: What partition type should I use for XFS on Linux? ==

Sandeen: /* Q: Why does userspace say "filesystem uses v1 dirs, limited functionality provided?" */

2016-12-05T21:04:01Z

Q: Why does userspace say "filesystem uses v1 dirs, limited functionality provided?"

← Older revision		Revision as of 21:04, 5 December 2016
Line 681:		Line 681:
	== Q: Why does userspace say "filesystem uses v1 dirs, limited functionality provided?" ==		== Q: Why does userspace say "filesystem uses v1 dirs, limited functionality provided?" ==

	Either you have a very old or a ~~very~~ new filesystem~~. Very~~ old ~~filesystems used a format called "directory version 1" and in this case the error is self explanatory~~.		Either you have a very old or a rather new filesystem coupled with too-old userspace.

	However, if you have a ~~new~~ filesystem with version 5 superblocks and the metadata CRC feature enabled, older releases of xfsprogs may incorrectly issue the "v1 dir" message. In this case, get newer xfsprogs; at least v3.2.0, but preferably the latest release.		Very old filesystems used a format called "directory version 1" and in this case the error is correct and hopefully self explanatory.

			However, if you have a newer filesystem with version 5 superblocks and the metadata CRC feature enabled, older releases of xfsprogs may incorrectly issue the "v1 dir" message. In this case, get newer xfsprogs; at least v3.2.0, but preferably the latest release.

Sandeen at 21:02, 5 December 2016

2016-12-05T21:02:57Z

← Older revision		Revision as of 21:02, 5 December 2016
Line 678:		Line 678:

	Note that if your raid is very dumb and/or has no cache enabled then it likely cannot reorder I/O requests and thus it could benefit from I/O scheduler.		Note that if your raid is very dumb and/or has no cache enabled then it likely cannot reorder I/O requests and thus it could benefit from I/O scheduler.

			== Q: Why does userspace say "filesystem uses v1 dirs, limited functionality provided?" ==

			Either you have a very old or a very new filesystem. Very old filesystems used a format called "directory version 1" and in this case the error is self explanatory.

			However, if you have a new filesystem with version 5 superblocks and the metadata CRC feature enabled, older releases of xfsprogs may incorrectly issue the "v1 dir" message. In this case, get newer xfsprogs; at least v3.2.0, but preferably the latest release.

Cattelan: /* SSD disks or rotational disks but with hardware raid card that has cache enabled */

2016-08-10T21:25:47Z

SSD disks or rotational disks but with hardware raid card that has cache enabled

← Older revision		Revision as of 21:25, 10 August 2016
Line 675:		Line 675:
	=== SSD disks or rotational disks but with hardware raid card that has cache enabled ===		=== SSD disks or rotational disks but with hardware raid card that has cache enabled ===

	Block multiqueue enabled (and thus no I/O scheduler at all) or block multiqueue disabled and noop or deadline I/O scheduler activated is good solution. SSD disks don't really need I/O schedulers while smart raid cards do I/O ordering on their own.		''Block multiqueue'' enabled (and thus no I/O scheduler at all) or block multiqueue disabled and ''noop'' or ''deadline'' I/O scheduler activated is good solution. SSD disks don't really need I/O schedulers while smart raid cards do I/O ordering on their own.

	Note that if your raid is very dumb and/or has no cache enabled then it likely cannot reorder I/O requests and thus it could benefit from I/O scheduler.		Note that if your raid is very dumb and/or has no cache enabled then it likely cannot reorder I/O requests and thus it could benefit from I/O scheduler.

Cattelan: /* On rotational disks without hardware raid */

2016-08-10T21:24:04Z

On rotational disks without hardware raid

← Older revision		Revision as of 21:24, 10 August 2016
Line 660:		Line 660:
	''CFQ'': not great for XFS parallelism:		''CFQ'': not great for XFS parallelism:

	< dchinner> it doesn't allow other threads to get IO issued immediately after the first one		< dchinner> it doesn't allow other threads to get IO issued immediately after the first one
	< dchinner> it waits, instead, for a timeslice to expire before moving to the IO of a different process.		< dchinner> it waits, instead, for a timeslice to expire before moving to the IO of a different process.
	< dchinner> so instead of interleaving the IO of multiple jobs in a single sweep across the disk, it enforces single threaded access to the disk		< dchinner> so instead of interleaving the IO of multiple jobs in a single sweep across the disk,
			it enforces single threaded access to the disk

	''deadline'': good option, doesn't have such problem		''deadline'': good option, doesn't have such problem

Cattelan: trying to explain which I/O scheduler is good choice for xfs. Based on dchinner knowledge (hopefully translated without errors into FAQ entry).

2016-08-10T21:22:55Z

trying to explain which I/O scheduler is good choice for xfs. Based on dchinner knowledge (hopefully translated without errors into FAQ entry).

← Older revision		Revision as of 21:22, 10 August 2016
Line 653:		Line 653:

	(http://oss.sgi.com/pipermail/xfs/2015-October/044457.html)		(http://oss.sgi.com/pipermail/xfs/2015-October/044457.html)

			== Q: Which I/O scheduler for XFS? ==

			=== On rotational disks without hardware raid ===

			''CFQ'': not great for XFS parallelism:

			< dchinner> it doesn't allow other threads to get IO issued immediately after the first one
			< dchinner> it waits, instead, for a timeslice to expire before moving to the IO of a different process.
			< dchinner> so instead of interleaving the IO of multiple jobs in a single sweep across the disk, it enforces single threaded access to the disk

			''deadline'': good option, doesn't have such problem

			Note that some kernels have block multiqueue enabled which (currently - 08/2016) doesn't support I/O schedulers at all thus there is no optimisation and reordering IO for best seek order, so disable blk-mq for rotational disks (see CONFIG_SCSI_MQ_DEFAULT, CONFIG_DM_MQ_DEFAULT options and use_blk_mq parameter for scsi-mod/dm-mod kernel modules).

			Also hardware raid can be smart enough to cache and reorder I/O requests thus additional layer of reordering
			(like Linux I/O scheduler) can potentially conflict and make performance worse. If you have such raid card
			then try method described below.

			=== SSD disks or rotational disks but with hardware raid card that has cache enabled ===

			Block multiqueue enabled (and thus no I/O scheduler at all) or block multiqueue disabled and noop or deadline I/O scheduler activated is good solution. SSD disks don't really need I/O schedulers while smart raid cards do I/O ordering on their own.

			Note that if your raid is very dumb and/or has no cache enabled then it likely cannot reorder I/O requests and thus it could benefit from I/O scheduler.

Sandeen: /* Q. Should barriers be enabled with storage which has a persistent write cache? */

2015-12-14T16:39:32Z

Q. Should barriers be enabled with storage which has a persistent write cache?

← Older revision		Revision as of 16:39, 14 December 2015
Line 250:		Line 250:
	== Q. Should barriers be enabled with storage which has a persistent write cache? ==		== Q. Should barriers be enabled with storage which has a persistent write cache? ==

	Many hardware ~~RAID~~ have a persistent write cache which ~~preserves it~~ across power failure, interface resets, system crashes, etc. ~~Using write barriers in this instance is not recommended and will in fact lower performance~~. ~~Therefore, it is recommended~~ to ~~turn off~~ the ~~barrier support~~ and ~~mount~~ the ~~filesystem with~~ "nobarrier", ~~assuming your RAID controller~~ is ~~infallible and~~ not ~~resetting randomly like some common ones do~~. ~~But take care about the hard disk~~ write cache, ~~which should be off~~.		Many hardware RAIDs have a persistent write cache which is preserved across power failure, interface resets, system crashes, etc. The same may be true of some SSD devices. This sort of hardware should report to the operating system that no flushes are required, and in that case barriers will not be issued, even without the "nobarrier" option. Quoting Christoph Hellwig [http://oss.sgi.com/archives/xfs/2015-12/msg00281.html on the xfs list],
			If the device does not need cache flushes it should not report requiring
			flushes, in which case nobarrier will be a noop. Or to phrase it
			differently: If nobarrier makes a difference skipping it is not safe.
			On modern kernels with hardware which properly reports write cache behavior, there is no need to change barrier options at mount time.

	== Q. Which settings does my RAID controller need ? ==		== Q. Which settings does my RAID controller need ? ==

Cattelan: Other link also fixed

2015-12-13T08:32:48Z

Cattelan: Fix url

2015-12-13T08:18:18Z

Fix url

← Older revision		Revision as of 08:18, 13 December 2015
Line 406:		Line 406:
	== Q: Why do I receive <tt>No space left on device</tt> after <tt>xfs_growfs</tt>? ==		== Q: Why do I receive <tt>No space left on device</tt> after <tt>xfs_growfs</tt>? ==

	After [http://oss.sgi.com/pipermail/xfs/2009-January/039828.html growing a XFS filesystem], df(1) would show enough free space but attempts to write to the filesystem result in -ENOSPC. This was an issue with the older "inode32" inode allocation mode, where inode allocation is restricted to lower filesysetm blocks. To fix this, [http://oss.sgi.com/~~pipermail~~/xfs/2009-~~January~~/~~039835~~.html Dave Chinner advised]:		After [http://oss.sgi.com/pipermail/xfs/2009-January/039828.html growing a XFS filesystem], df(1) would show enough free space but attempts to write to the filesystem result in -ENOSPC. This was an issue with the older "inode32" inode allocation mode, where inode allocation is restricted to lower filesysetm blocks. To fix this, [http://oss.sgi.com/archives/xfs/2009-01/msg01031.html Dave Chinner advised]:

	The only way to fix this is to move data around to free up space		The only way to fix this is to move data around to free up space

← Older revision		Revision as of 08:32, 13 December 2015
Line 406:		Line 406:
	== Q: Why do I receive <tt>No space left on device</tt> after <tt>xfs_growfs</tt>? ==		== Q: Why do I receive <tt>No space left on device</tt> after <tt>xfs_growfs</tt>? ==

	After [http://oss.sgi.com/~~pipermail~~/xfs/2009-~~January~~/~~039828~~.html growing a XFS filesystem], df(1) would show enough free space but attempts to write to the filesystem result in -ENOSPC. This was an issue with the older "inode32" inode allocation mode, where inode allocation is restricted to lower filesysetm blocks. To fix this, [http://oss.sgi.com/archives/xfs/2009-01/msg01031.html Dave Chinner advised]:		After [http://oss.sgi.com/archives/xfs/2009-01/msg01023.html growing a XFS filesystem], df(1) would show enough free space but attempts to write to the filesystem result in -ENOSPC. This was an issue with the older "inode32" inode allocation mode, where inode allocation is restricted to lower filesysetm blocks. To fix this, [http://oss.sgi.com/archives/xfs/2009-01/msg01031.html Dave Chinner advised]:

	The only way to fix this is to move data around to free up space		The only way to fix this is to move data around to free up space