xfs.org - User contributions [en]

Shrinking Support

2019-03-10T21:41:39Z

Ckujau: mod_speling; https upgrades

Currently XFS Filesystems can't be shrunk.

To support shrinking XFS filesystems a few things needs to be implemented, based on a list by Dave Chinner [https://marc.info/?l=linux-xfs&m=118091640624488&]:

* A way to check space is available for shrink

* An ioctl or similar interface to prevent new allocations from a given allocation group.

* A variant of the xfs_reno tool to support moving inodes out of filesystem areas that go away.

* A variant of the xfs_fsr tool to support moving data out of the filesystem areas that go away.

* Some way to move out orphan metadata out of the AGs truncated off

* A transaction to shrink the filesystem.

At that point, we'll have a "working" shrink that will allow
shrinking to only 50% of the original size because the log
(in the middle of the filesystem) will
get in the way. To fix that, we'll need to implement transactions
to move the log...

== Available pieces ==

* A script from Ruben Porras to check if enough free space is available to support shrinking.[https://marc.info/?l=linux-xfs&m=118581682117599]

* A patch from Ruben Porras to allow / disallow allocation from an allocation group [https://marc.info/?l=linux-xfs&m=118302806818420] plus userspace support for setting / clearing it [https://marc.info/?l=linux-xfs&m=118881137031101]

* The xfs_fsr tool in xfsprogs

* The xfs_reno tool, see [[Unfinished_work#The_xfs_reno_tool]]

* An untested patch from Dave Chinner for a xfs_swap_inodes ioctl that allows to not just defragment extents but moving the whole inode [https://marc.info/?l=linux-xfs&m=119552278931942] and a patch to xfs_reno to use it from Ruben Porras [https://marc.info/?l=linux-xfs&m=119582841808985]

User:Ckujau

2016-05-29T00:24:16Z

Ckujau: dot

[mailto:xfswiki_at_nerdbynature_dot_de Christian Kujau]

* [[/maintenance/]]

XFS email list and archives

2016-02-01T10:20:50Z

Ckujau: 404s removed; Spinics added

== XFS email list ==
Patches, comments, requests and questions should go to [mailto:xfs@oss.sgi.com xfs@oss.sgi.com]

The list archives on oss.sgi.com are available [http://oss.sgi.com/archives/xfs here] (MHonArc) and [http://oss.sgi.com/pipermail/xfs here] (mailman).

Other archives include:

* [http://news.gmane.org/group/gmane.comp.file-systems.xfs.general Gmane]
* [https://www.spinics.net/lists/xfs/ Spinics]
* [http://www.opensubscriber.com/messages/xfs@oss.sgi.com/topic.html OpenSubscriber]

== Subscribing to the list ==

The easiest method is to use the [http://oss.sgi.com/mailman/listinfo/xfs mailman web interface].

Subscribing is also possible by sending an email with the body:

<pre>subscribe</pre>

to [mailto:xfs-request@oss.sgi.com?body=subscribe xfs-request@oss.sgi.com]

XFS Papers and Documentation

2015-10-15T18:17:26Z

Ckujau: s/Image/File/

=== Primary XFS Documentation ===

The XFS documentation started by SGI has been converted to docbook/[https://fedorahosted.org/publican/ Publican] format. The material is suitable for experienced users as well as developers and support staff. The XML source is available in a [http://git.kernel.org/?p=fs/xfs/xfsdocs-xml-dev.git;a=summary git repository] and builds of the documentation are available here:

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.html XFS User Guide]

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html XFS File System Structure]
** [http://sites.google.com/site/kandamotohiro/xfs Japanese translation] is also available.

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Labs/tmp/en-US/html/index.html XFS Training Labs]

* (Original versions of this material are still available at [http://oss.sgi.com/projects/xfs/training/index.html XFS Overview and Internals (html)] and [http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf XFS Filesystem Structure (pdf)]

The format of <tt>/proc/fs/xfs/stat</tt> also has been documented:
* [[Runtime_Stats|Runtime_Stats]]

=== Papers, Presentations, Etc ===

At the linux.conf.au 2012 event, Dave Chinner presented a talk on filesystem metadata scalability:

* ''XFS - Recent and Future Adventures in Filesystem Scalability'' [[http://www.youtube.com/watch?v=FegjLbCnoBw Video]] [ [[:File:Xfs-scalability-lca2012.pdf|Presentation Slides]] ]

The October 2009 issue of the USENIX ;login: magazine published an article about XFS targeted at system administrators:

* ''XFS: The big storage file system for Linux'' [[http://oss.sgi.com/projects/xfs/papers/hellwig.pdf pdf]]

At the Ottawa Linux Symposium (July 2006), Dave Chinner presented a paper on filesystem scalability in Linux 2.6 kernels:

* ''High Bandwidth Filesystems on Large Systems'' (July 2006) [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf paper]] [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-presentation.pdf presentation]]

At linux.conf.au 2008 Dave Chinner gave a presentation about xfs_repair that he co-authored with Barry Naujok:

* Fixing XFS Filesystems Faster [[http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf pdf]]

In July 2006, SGI storage marketing updated the XFS datasheet:

* ''Open Source XFS for Linux'' [[http://oss.sgi.com/projects/xfs/datasheet.pdf pdf]]

At UKUUG 2003, Christoph Hellwig presented a talk on XFS:

* ''XFS for Linux'' (July 2003) [[http://oss.sgi.com/projects/xfs/papers/ukuug2003.pdf pdf]] [[http://verein.lst.de/~hch/talks/ukuug2003/ html]]

Originally published in Proceedings of the FREENIX Track: 2002 Usenix Annual Technical Conference:

* ''Filesystem Performance and Scalability in Linux 2.4.17'' (June 2002) [[http://oss.sgi.com/projects/xfs/papers/filesystem-perf-tm.pdf pdf]]

At the Ottawa Linux Symposium, an updated presentation on porting XFS to Linux was given:

* ''Porting XFS to Linux'' (July 2000) [[http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm html]]

At the Atlanta Linux Showcase, SGI presented the following paper on the port of XFS to Linux:

* ''Porting the SGI XFS File System to Linux'' (October 1999) [[http://oss.sgi.com/projects/xfs/papers/als/als.ps ps]] [[http://oss.sgi.com/projects/xfs/papers/als/als.pdf pdf]]

At the 6th Linux Kongress & the Linux Storage Management Workshop (LSMW) in Germany in September, 1999, SGI had a few presentations including the following:

* ''SGI's port of XFS to Linux'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/linux_kongress/index.htm html]]
* ''Overview of DMF'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/DMF-over/index.htm html]]

At the LinuxWorld Conference & Expo in August 1999, SGI published:

* ''An Open Source XFS data sheet'' (August 1999) [[http://oss.sgi.com/projects/xfs/papers/xfs_GPL.pdf pdf]]

From the 1996 USENIX conference:

* ''An XFS white paper'' [[http://oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html html]]

=== Other historical articles, press-releases, etc ===

* IBM's ''Advanced Filesystem Implementor's Guide'' has a chapter ''Introducing XFS'' [[http://www-106.ibm.com/developerworks/library/l-fs9.html html]]

* An editorial titled ''Tired of fscking? Try a journaling filesystem!'', Freshmeat (February 2001) [[http://freshmeat.net/articles/view/212/ html]]

* ''Who give a fsck about filesystems'' provides an overview of the Linux 2.4 filesystems [[http://www.linuxuser.co.uk/articles/issue6/lu6-All_you_need_to_know_about-Filesystems.pdf html]]

* ''Journal File Systems'' in issue 55 of ''Linux Gazette'' provides a comparison of journaled filesystems.

* The original XFS beta release announcement was published in ''Linux Today'' (September 2000) [[http://linuxtoday.com/news_story.php3?ltsn=2000-09-26-017-04-OS-SW html]]

* ''XFS: It's worth the wait'' was published on ''EarthWeb'' (July 2000) [[http://networking.earthweb.com/netos/oslin/article/0,,12284_623661,00.html html]]

* An ''IRIX-XFS data sheet'' (July 1999) [[http://oss.sgi.com/projects/xfs/papers/IRIX_xfs_data_sheet.pdf pdf]]

* The ''Getting Started with XFS'' book (1994) [[http://oss.sgi.com/projects/xfs/papers/getting_started_with_xfs.pdf pdf]]

* Original ''XFS design documents'' (1993) ([http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_ps/ ps], [http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/ pdf])

User:Ckujau

2015-04-14T16:57:50Z

Ckujau: rot13'ed, again :)

[mailto:xfswiki@nerdbynature.de Christian Kujau]

* [[/maintenance/]]

User:Ckujau/maintenance

2015-04-14T16:52:56Z

Ckujau: maintenance page update

* [[Special:BrokenRedirects]]
* [[Special:DeadendPages]]
* [[Special:DoubleRedirects]]
* [[Special:Lonelypages]]
* [[Special:UncategorizedCategories]]
* [[Special:UncategorizedFiles]]
* [[Special:UncategorizedPages]]
* [[Special:UncategorizedTemplates]]
* [[Special:UnusedCategories]]
* [[Special:UnusedFiles]]
* [[Special:UnusedTemplates]]
* [[Special:WantedCategories]]
* [[Special:WantedFiles]]
* [[Special:WantedPages]]
* [[Special:WantedTemplates]]

<small><div align=right>v{{CURRENTVERSION}}/{{CONTENTLANGUAGE}}</div></small>

Getting the latest source code

2015-01-23T02:05:39Z

Ckujau: s/i sno/is no/

== <font face="ARIAL NARROW,HELVETICA"> XFS Released/Stable source </font> ==

* '''Mainline kernels'''
:XFS has been maintained in the official Linux kernel [http://www.kernel.org/ kernel trees] starting with [http://lkml.org/lkml/2003/12/8/35 Linux 2.4] and is frequently updated with the latest stable fixes and features from the XFS development team.

* '''Vendor kernels'''
:All modern Linux distributions include support for XFS.

* '''XFS userspace'''
:[ftp://oss.sgi.com/projects/xfs source code tarballs] of the xfs userspace tools. These tarballs form the basis of the xfsprogs packages found in Linux distributions.

== <font face="ARIAL NARROW,HELVETICA"> Development and bleeding edge Development </font> ==

* [[XFS git howto]]

=== Current XFS kernel source ===

* [https://git.kernel.org/cgit/linux/kernel/git/dgc/linux-xfs.git/ xfs]

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git

Note: the old kernel tree on [http://oss.sgi.com/cgi-bin/gitweb.cgi oss.sgi.com] is no longer kept up to date with the master tree on kernel.org.

=== XFS user space tools ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=summary xfsprogs]

git clone git://oss.sgi.com/xfs/cmds/xfsprogs

A few packages are needed to compile <tt>xfsprogs</tt>, depending on your package manager:

apt-get install libtool automake gettext libblkid-dev uuid-dev
yum install libtool automake gettext libblkid-devel libuuid-devel

=== XFS dump ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsdump.git;a=summary xfsdump]
$ git clone git://oss.sgi.com/xfs/cmds/xfsdump

=== XFS tests ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git;a=summary xfstests]
$ git clone git://oss.sgi.com/xfs/cmds/xfstests

=== DMAPI user space tools ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/dmapi.git;a=summary dmapi]
$ git clone git://oss.sgi.com/xfs/cmds/dmapi

=== git-cvsimport generated trees ===

The Git trees are automated mirrored copies of the CVS trees using [http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html git-cvsimport].
Since git-cvsimport utilized the tool [http://www.cobite.com/cvsps/ cvsps] to recreate the atomic commits of ptools or "mod" it is easier to see the entire change that was committed using git.

* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=summary linux-2.6-xfs-from-cvs]
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-cmds.git;a=summary xfs-cmds]

Before building in the <tt>xfsdump</tt> or <tt>dmapi</tt> directories (after building <tt>xfsprogs</tt>), you will need to run:
# cd xfsprogs
# make install-dev
to create <tt>/usr/include/xfs</tt> and install appropriate files there.

Before building in the xfstests directory, you will need to run:
# cd xfsprogs
# make install-qa
to install a somewhat larger set of files in <tt>/usr/include/xfs</tt>.

== <font face="ARIAL NARROW,HELVETICA">XFS cvs trees </font> ==

The cvs trees were created using a script that converted sgi's internal
ptools repository to a cvs repository, so the cvs trees were considered read only.

At this point all new development is being managed by the git trees thus the cvs trees
are no longer active in terms of current development and should only be used
for reference.

* [[XFS CVS howto]]

Getting the latest source code

2014-05-21T18:23:35Z

Ckujau: formatting snafu fixed

== <font face="ARIAL NARROW,HELVETICA"> XFS Released/Stable source </font> ==

* '''Mainline kernels'''
:XFS has been maintained in the official Linux kernel [http://www.kernel.org/ kernel trees] starting with [http://lkml.org/lkml/2003/12/8/35 Linux 2.4] and is frequently updated with the latest stable fixes and features from the SGI XFS development team.

* '''Vendor kernels'''
:All modern Linux distributions include support for XFS. SGI actively works with [http://www.suse.com/ SUSE] to provide a supported version of XFS in that distribution.

* '''XFS userspace'''
:Sgi also provides [ftp://oss.sgi.com/projects/xfs source code tarballs] of the xfs userspace tools. These tarballs form the basis of the xfsprogs packages found in Linux distributions.

== <font face="ARIAL NARROW,HELVETICA"> Development and bleeding edge Development </font> ==

* [[XFS git howto]]

Note: there are also [http://git.kernel.org/?s=xfs XFS git repositories on kernel.org] for external (i.e. non-Sgi) contributers. Sgi periodically pulls those in to [http://oss.sgi.com/cgi-bin/gitweb.cgi oss.sgi.com]. This also means that one or the other may be a bit more current.

=== Current XFS kernel source ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=summary xfs]
$ git clone git://oss.sgi.com/xfs/xfs

=== XFS user space tools ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=summary xfsprogs]

git clone git://oss.sgi.com/xfs/cmds/xfsprogs

A few packages are needed to compile <tt>xfsprogs</tt>, depending on your package manager:

apt-get install libtool automake gettext libblkid-dev uuid-dev
yum install libtool automake gettext libblkid-devel libuuid-devel

=== XFS dump ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsdump.git;a=summary xfsdump]
$ git clone git://oss.sgi.com/xfs/cmds/xfsdump

=== XFS tests ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git;a=summary xfstests]
$ git clone git://oss.sgi.com/xfs/cmds/xfstests

=== DMAPI user space tools ===
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/dmapi.git;a=summary dmapi]
$ git clone git://oss.sgi.com/xfs/cmds/dmapi

=== git-cvsimport generated trees ===

The Git trees are automated mirrored copies of the CVS trees using [http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html git-cvsimport].
Since git-cvsimport utilized the tool [http://www.cobite.com/cvsps/ cvsps] to recreate the atomic commits of ptools or "mod" it is easier to see the entire change that was committed using git.

* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=summary linux-2.6-xfs-from-cvs]
* [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-cmds.git;a=summary xfs-cmds]

Before building in the <tt>xfsdump</tt> or <tt>dmapi</tt> directories (after building <tt>xfsprogs</tt>), you will need to run:
# cd xfsprogs
# make install-dev
to create <tt>/usr/include/xfs</tt> and install appropriate files there.

Before building in the xfstests directory, you will need to run:
# cd xfsprogs
# make install-qa
to install a somewhat larger set of files in <tt>/usr/include/xfs</tt>.

== <font face="ARIAL NARROW,HELVETICA">XFS cvs trees </font> ==

The cvs trees were created using a script that converted sgi's internal
ptools repository to a cvs repository, so the cvs trees were considered read only.

At this point all new development is being managed by the git trees thus the cvs trees
are no longer active in terms of current development and should only be used
for reference.

* [[XFS CVS howto]]

User talk:Cattelan

2012-10-19T19:07:55Z

Ckujau: reply

== XFS_IOCORE_R ==

To Developers ,
I have read about the new member named as xfs_extdelta that is passed in different xfs internal routines i.e xfs_bmapi , In the 2.4 versions instead of using it is just passed as NULL can anyone provide info regarding that where to initialize and if I pass it NULl then is there any adverse effect of it

XFS_IOCORE_RT not been used in 2.6 version , so if instead of this flag I will pass XFS_IOCORE_EXCL it will be ok or will cause any crash or adverse effects or either there is any alternative present to sought out from these two problems

Regards
Anshul Kundra
HCL TECHNOLOGIES
ERS
: Has been answered on the [http://www.spinics.net/lists/xfs/msg09007.html mailinglist] -- [[User:Ckujau|Ckujau]] 23:39, 16 February 2012 (UTC)

== XFS File Inode number is changing using the utilities ==

To Developers,

I have seen a different behaviour in XFS

Suppose I have a file with inode number "131", I have noticed that the inode number of file got changed without deleting the file. When we change the data of the file everytime it changes the inode number. The complete description over the test is as follows

Steps are as follows:

1) I have created a file using "dd" of size 100MB:

#dd if=/dev/zero of=xfs.img bs=1M count=100

2) Created a loopback device over the image:
#losetup /dev/loop1 xfs.img

3) Created file system:
#mkfs.xfs /dev/loop1

4) Mounted:
#mount /dev/loop1 /mnt/xfs_mnt

5) Please check the mount output:
# mount

/dev/sdb2 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
devtmpfs on /dev type devtmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/loop0 on /mnt/mount_test type xfs (rw)
/dev/loop1 on /mnt/xfs_mnt type xfs (rw)

6) Created a file using "touch"

# touch kundra.txt

7) Checking the file and its inode number:

# ls -li
total 0
131 -rw-r--r-- 1 root root 0 2012-10-20 01:41 kundra.txt

8) I have written some data using the vim editor, I can't provide snapshot of vim on the list:

#vim kundra.txt

9) Now I checked the inode number using the "ls -li"
# ls -li

total 4
133 -rw-r--r-- 1 root root 19 2012-10-20 01:43 kundra.txt

Please check that the inode number ( from "131" to "133" ) and total value (from "0" to "4" )in the filesystem got changed, I am assuming that the reasom may be due to filesystem of small size but it is showing unexpected behaviour.

Please provide some description over this issue, I am working on Linux SLES

# cat /etc/issue

Welcome to SUSE Linux Enterprise Server 11 SP1 (x86_64) - Kernel \r (\l).

# uname -a
Linux linux-sles 2.6.32.19-0.6-default #1 SMP Fri Aug 31 01:37:50 IST 2012 x86_64 x86_64 x86_64 GNU/Linux

Thanks & Best Regards
Anshul Kundra
: Anshul, as I have suggested [[User:Anshul.kundra|earlier]]: please ask questions on the [[XFS_email_list_and_archives|mailing lists]]. Also, your question [https://encrypted.google.com/search?hl=en&q=vi%20inode%20change has been answered many times] already. -- [[User:Ckujau|Ckujau]] ([[User talk:Ckujau|talk]]) 19:07, 19 October 2012 (UTC)

Xfs.org talk:Anshul.kundra

2012-10-15T17:37:28Z

Ckujau: namespace cleanup, moved back to User:Anshul.kundra

Talk:XFS Status Updates

2012-03-19T21:43:35Z

Ckujau:

= quite/quiet =

Someone's annoyingly dyslexic:
"quite" == totally/actually;
"quiet" == low level of noise/silent.
: (Hopefully) fixed. Why didn't you? -- [[User:Christian|chris_goe]] 20:54, 3 April 2011 (UTC)

Teach a man to fish, and all that ;)

= Combined status page =

Out of curiosity: why was the status page split up? Was it too long to be edited? Or, asked another way: is there a need for a combined status page, with '''all''' the statuses on one page, as before? This could be achived through article inclusion, e.g.
<nowiki>{{:XFS_status_update_for_2012}}</nowiki>
<nowiki>{{:XFS_status_update_for_2011}}</nowiki>
:This would include the statuses from 2012 and 2011 on a single page, yet each year would still have its own page. -- [[User:Ckujau|Ckujau]] 21:43, 19 March 2012 (UTC)

FITRIM/discard

2012-03-17T03:23:54Z

Ckujau: SPAM: Undo revision 2433 by Vegasseo (Talk)

== Purpose ==

FITRIM is a mounted filesystem feature to discard (or "[https://en.wikipedia.org/wiki/TRIM trim]") blocks which are not in use by the filesystem. This is useful for solid-state drives (SSDs) and thinly-provisioned storage.

== Requirements ==

#The block device underneath the filesystem must support the FITRIM operation.
#The kernel must include TRIM support and XFS must include FITRIM support (this has been true for Linux since v2.6.38, Jan 18 2011)
#Realtime discard mode requires a more recent v3.0 kernel

This can be verified by viewing /sys/block/<dev>/queue/discard_max_bytes -- If the value is zero then your device doesn't support discard
operations.

== Modes of Operation ==

* Realtime discard -- As files are removed, the filesystem issues discard requests automatically
* Batch Mode -- A user procedure that trims all or portions of the filesystem

=== Realtime discard ===

This mode issues discard requests automatically as files are removed from the filesystem. No other command or process is required.

There can be a severe performance penalty for enabling realtime discard. (4)

Realtime discard is selected by adding the filesystem option <code>discard</code> while mounting.

This can be done by the following examples:

# placing <code>discard</code> in your /etc/fstab for the filesystem: <code>/dev/sda1 /mountpoint xfs defaults,discard 0 1</code>
# mount options: <code>mount -o discard /dev/sda1 /mountpoint</code>

=== Batch Mode ===

This mode requires user intervention. This intervention is in the form of the command <code>fstrim</code>. It has been included in [https://en.wikipedia.org/wiki/Util-linux util-linux-ng] since about Nov 26, 2010.

Usage example:
<code>fstrim /mountpoint</code>

----

== References ==
# FITRIM description - Lukas Czerner <lczerner at redhat.com> http://patchwork.xfs.org/patch/1490/
# Block requirements - Dave Chinner <david at fromorbit.com> http://oss.sgi.com/pipermail/xfs/2011-October/053379.html
# util-linux-ng addition - Karel Zak <kzak@xxxxxxxxxx> http://www.spinics.net/lists/util-linux-ng/msg03646.
# Online TRIM/discard performance impact - http://oss.sgi.com/pipermail/xfs/2011-November/053841.html

File:Xfs-scalability-lca2012.pdf

2012-02-16T23:48:09Z

Ckujau: +title, date

Title: XFS: Adventures in Metadata Scalability
Author: Dave Chinner
Date: 2012-01-18

XFS Papers and Documentation

2012-02-16T23:45:01Z

Ckujau: link wikified

=== Primary XFS Documentation ===

The XFS documentation started by SGI has been converted to docbook/[https://fedorahosted.org/publican/ Publican] format. The material is suitable for experienced users as well as developers and support staff. The XML source is available in a [http://git.kernel.org/?p=fs/xfs/xfsdocs-xml-dev.git;a=summary git repository] and builds of the documentation are available here:

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.html XFS User Guide]

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html XFS File System Structure]
** [http://sites.google.com/site/kandamotohiro/xfs Japanese translation] is also available.

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Labs/tmp/en-US/html/index.html XFS Training Labs]

* (Original versions of this material are still available at [http://oss.sgi.com/projects/xfs/training/index.html XFS Overview and Internals (html)] and [http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf XFS Filesystem Structure (pdf)]

The format of <tt>/proc/fs/xfs/stat</tt> also has been documented:
* [[Runtime_Stats|Runtime_Stats]]

=== Papers, Presentations, Etc ===

At the linux.conf.au 2012 event, Dave Chinner presented a talk on filesystem metadata scalability:

* ''XFS - Recent and Future Adventures in Filesystem Scalability'' [[http://www.youtube.com/watch?v=FegjLbCnoBw Video]] [ [[:Image:Xfs-scalability-lca2012.pdf|Presentation Slides]] ]

The October 2009 issue of the USENIX ;login: magazine published an article about XFS targeted at system administrators:

* ''XFS: The big storage file system for Linux'' [[http://oss.sgi.com/projects/xfs/papers/hellwig.pdf pdf]]

At the Ottawa Linux Symposium (July 2006), Dave Chinner presented a paper on filesystem scalability in Linux 2.6 kernels:

* ''High Bandwidth Filesystems on Large Systems'' (July 2006) [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf paper]] [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-presentation.pdf presentation]]

At linux.conf.au 2008 Dave Chinner gave a presentation about xfs_repair that he co-authored with Barry Naujok:

* Fixing XFS Filesystems Faster [[http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf pdf]]

In July 2006, SGI storage marketing updated the XFS datasheet:

* ''Open Source XFS for Linux'' [[http://oss.sgi.com/projects/xfs/datasheet.pdf pdf]]

At UKUUG 2003, Christoph Hellwig presented a talk on XFS:

* ''XFS for Linux'' (July 2003) [[http://oss.sgi.com/projects/xfs/papers/ukuug2003.pdf pdf]] [[http://verein.lst.de/~hch/talks/ukuug2003/ html]]

Originally published in Proceedings of the FREENIX Track: 2002 Usenix Annual Technical Conference:

* ''Filesystem Performance and Scalability in Linux 2.4.17'' (June 2002) [[http://oss.sgi.com/projects/xfs/papers/filesystem-perf-tm.pdf pdf]]

At the Ottawa Linux Symposium, an updated presentation on porting XFS to Linux was given:

* ''Porting XFS to Linux'' (July 2000) [[http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm html]]

At the Atlanta Linux Showcase, SGI presented the following paper on the port of XFS to Linux:

* ''Porting the SGI XFS File System to Linux'' (October 1999) [[http://oss.sgi.com/projects/xfs/papers/als/als.ps ps]] [[http://oss.sgi.com/projects/xfs/papers/als/als.pdf pdf]]

At the 6th Linux Kongress & the Linux Storage Management Workshop (LSMW) in Germany in September, 1999, SGI had a few presentations including the following:

* ''SGI's port of XFS to Linux'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/linux_kongress/index.htm html]]
* ''Overview of DMF'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/DMF-over/index.htm html]]

At the LinuxWorld Conference & Expo in August 1999, SGI published:

* ''An Open Source XFS data sheet'' (August 1999) [[http://oss.sgi.com/projects/xfs/papers/xfs_GPL.pdf pdf]]

From the 1996 USENIX conference:

* ''An XFS white paper'' [[http://oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html html]]

=== Other historical articles, press-releases, etc ===

* IBM's ''Advanced Filesystem Implementor's Guide'' has a chapter ''Introducing XFS'' [[http://www-106.ibm.com/developerworks/library/l-fs9.html html]]

* An editorial titled ''Tired of fscking? Try a journaling filesystem!'', Freshmeat (February 2001) [[http://freshmeat.net/articles/view/212/ html]]

* ''Who give a fsck about filesystems'' provides an overview of the Linux 2.4 filesystems [[http://www.linuxuser.co.uk/articles/issue6/lu6-All_you_need_to_know_about-Filesystems.pdf html]]

* ''Journal File Systems'' in issue 55 of ''Linux Gazette'' provides a comparison of journaled filesystems.

* The original XFS beta release announcement was published in ''Linux Today'' (September 2000) [[http://linuxtoday.com/news_story.php3?ltsn=2000-09-26-017-04-OS-SW html]]

* ''XFS: It's worth the wait'' was published on ''EarthWeb'' (July 2000) [[http://networking.earthweb.com/netos/oslin/article/0,,12284_623661,00.html html]]

* An ''IRIX-XFS data sheet'' (July 1999) [[http://oss.sgi.com/projects/xfs/papers/IRIX_xfs_data_sheet.pdf pdf]]

* The ''Getting Started with XFS'' book (1994) [[http://oss.sgi.com/projects/xfs/papers/getting_started_with_xfs.pdf pdf]]

* Original ''XFS design documents'' (1993) ([http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_ps/ ps], [http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/ pdf])

User talk:Cattelan

2012-02-16T23:39:25Z

Ckujau: see http://www.spinics.net/lists/xfs/msg09007.html

User talk:59.151.53.100

2012-02-16T23:29:03Z

Ckujau: spam!

XFS Status Updates

2012-02-09T17:39:16Z

Ckujau: s/quite/quiet/

== XFS status update for December 2011 ==

December saw further stabilization of the Linux 3.2 release candidates.
For XFS that meant two important fixes for sync() data integrity, to
work around issues introduced in the VFS sync code in the past few
kernel releases. These fixes have also been backported to the 3.0-stable
release.

Development for the next merge windows continue in fast pace, although
only a relatively small amount of patches was merged into the development
tree for the Linux 3.3 window. The most interesting topic in December
probably was further development of the SEEK_DATA / SEEK_HOLE support,
including defining the exact semantics in presence of unwritten extents
and proper test coverage.

On the user space side December was fairly quiet, with about a handful
fixes commit to xfsprogs, two new test cases and a couple of fixes in
xfstests, and no activity in xfsdump.

== XFS status update for November 2011 ==

November saw stabilization of the Linux 3.2 release candidates, including
a few fixes for XFS. In addition a lot of bug fixes were backported to
the 3.0 long term stable and 3.1-stable releases for users not on
bleeding edge kernels.

At the same time development for Linux 3.3 went on at a fast pace, although
no pages were merged into the development tree yet. The highlights are:

- further versions of the patches to log all file size updates instead of
relying the the flaky VM writeback code for them
- an initial version of SEEK_HOLE/SEEK_DATA support
- removal of the old non-delaylog logging code, and cleanups resulting
from the removal
- large updates for the quota code

Userspace development was even more busy:

Xfsprogs saw the rushed 3.1.7 release which contains Debian packaging fixes,
a polish translation update and a xfs_repair fix. In the meantime a lot of
xfs_repair fixes were posted but mostly not reviewed and commit yet.

Xfsdump grew support for using pthreads to write backup streams to multiple
tapes in parallel, and SGI_XFSDUMP_SKIP_FILE which has been deprecated in
favor of the nodump flag has finally been removed.
Xfstests saw an enormous amount of updates. The fsstress tool saw major
updates to exercise even more system calls, and found numerous bugs in
all major Linux filesystems, additional ENOSPC tests, a new test for
btrfs-specific functionality and the usual amount of bug fixes and small
cleanups. Also a series to clean up the very large filesystem testing,
including extending the support to ext4 was posted but not committed yet.

== XFS status update for October 2011 ==

October finally saw the delayed release of Linux 3.1, which is a fairly
boring release as XFS is concerned. In addition to a few bug fixes
and cleanups the biggest item is an XFS-internal re organization of the
source files, dropping all sub directories under fs/xfs.

Due to the long Linux 3.1 release cycle development for 3.3 has already
started full steam in October while adding a few more small optimization
and fixes to the development tree for Linux 3.2, and merging that tree
into mainline.

Notable items for Linux 3.2 are speedup for parallel O_DIRECT reads and
writes on high IOPS devices, optimizations for fsync(2) on directories
and sync(2) latency, as well as further small improvements for metadata
performance on highly parallel workloads.

On the user space side xfsprogs saw a few more xfs_repair fixes, as well
as some updates of mount point handling for the xfs_quota tools, which
together with the updates from the last months was published in form
of the xfsprogs 3.1.6 release. This was accompanied by an xfsdump
3.0.6 release, which does not include any new updates in October, but
lots of work from the previous month. Xfstests saw two additional
test cases and various fixes, and it's first versioned release ever.

== XFS status update for September 2011 ==

August saw further release candidates of Linux 3.1, which had been
completely uneventful with just a single small regression fix being
merged.

In the meantime developments for the Linux 3.2 kernel went on with the merge
of a large series that completely refactors the XFS-internal xfs_bmapi
interfaces for simpler interfaces and less stack usage, as well as various
smaller cleanups and fixes.

September also was a very busy month for userspace development. In xfsprogs
we saw various error handling fixes to libxcmd, libxfs, mkfs.xfs, xfs_quota
and xfs_repair, xfsdump saw a few smaller changes finishing up the large
work done in August. Xfstests saw 4 new test cases contributed from
various developers, and the usual handful of bug fixes.

== XFS status update for August 2011 ==

August saw further release candidates of Linux 3.1, which had been quiet
for XFS except for the bulk renaming of many XFS source files so that all
source files are now located directly underneath the fs/xfs/ directory.

A lot of development for the Linux 3.2 kernel series was going on,
including an overhaul of the data I/O completion handler, further buffer
cache speedups and cleanups, a major refactoring around xfs_bmapi, quota
locking changes, and optimization for direct I/O on high IOP solid state
devices.

On the userspace side xfsdump saw a lot of cleanups in preparation of porting
the multithreaded dump and restore code from IRIX. Xfsprogs saw a few fix
to the xfs_quota tool and mkfs.xfs as well as a man page update. This month
xfstests did not see any new test cases, but it got the usual amount of fixes
and grew support for jfs and NFS v4.

== XFS status update for July 2011 ==

July finally saw the release of Linux 3.0, including a relatively small XFS
update:

37 files changed, 1168 insertions(+), 847 deletions(-)

The primary news in this release is a complete rework of the busy extent
tracking, which speeds up allocation heavy multithreaded workloads. This
feature also allowed adding support for discard support at transaction
commit time using the discard mount option. While the implementation of
discards in XFS is state of the art it should be considered mostly a
technology preview until various efficiency issue in the block layer
discard support are sorted out. Another important feature visible to
users is that XFS now supports using external logs even when using volatile
write caches, although the implementation is not fully optimized yet,
the rest of the changes consists of the usual pile of bug fixes and a
relatively small set of cleanups. After the release of Linux 3.0 the
merge window for Linux 3.1 also fell mostly into July. The XFS merge
for 3.1 included further speedups for the AIL code, and a huge amount
of cleanups.

On the userspace side the biggest item was the merge of the libxfs resync
with the Linux 2.6.39 kernel code. In addition to that xfsprogs saw small
xfs_repair updates, xfstests saw various fixes to fsx, and various build
system fixes were commit to all userspace repositories.

== XFS status update for June 2011 ==

In June we saw more release candidates for Linux 3.0, which contain a few
XFS fixes, but no major updates. No updates were committed to the XFS
development tree for Linux 3.1 either, although the mailing list has been
rather busy with updates for that merge window.

On the user space side the xfsprogs and xfsdump repositories didn't see
any updates, while xfstests has been rather busy with a lot of fixes
to various test cases.

== XFS status update for May 2011 ==

May finally saw the release of Linux 2.6.39, which was a little more calm
than usual for XFS, and only contains about half the amount of the changes
we are used to see:

58 files changed, 1660 insertions(+), 1912 deletions(-)

The most visible change is an overhaul of the XFS-internal interfaces
to print kernel messages, which makes all messages from XFS look slightly
different from before by always providing information about which device
these messages relate to. In addition to that support for the RT subvolume,
which had been broken for a while has been resurrect, the XFS buffer cache
switched away from using the Linux pagecache to improve performance on
metadata intensive workloads, and all but one of the XFS kernel threads have
been switched to the new concurrent managed workqueue infrastructure that
is present in more recent Linux 2.6 releases.

In the meantime development for the release now known as Linux 3.0 went
ahead full steam up to the merge of the XFS tree into Linux 3.0-rc1. News
in that release contain support for vastly improved busy extent tracking,
support for online discard (aka TRIM) and the usual amount of bug fixes.

On the user space side the xfsprogs saw a fix for a corner case in xfs_repair,
and xfstests saw a few bug fixes as well as a new test case to test
btrfs-specific functionality.

== XFS status update for April 2011 ==

April saw further stabilization work on the Linux 2.6.39 kernel, including
a number of XFS bug fixes. Most importantly a series of patches fixes various
OOM problems due to bad interactions between the generic writeback code
and XFS inode reclaim, but there also were other patches for various smaller
issues. In the meantime the XFS development tree saw the addition of the
optimized busy extent tracking, which allows large speedups for multi-threaded
meta data heavy workloads, and lays the groundwork for discard support on
transaction commit, and a few other smaller patches.

On the user space side the xfsprogs and xfsdump repositories saw a very quiet
month with no applied patches, although a few were posted and discussed on
the mailing list. The xfstests repository on the other hand saw a new test
cases exercising the xfs_metadump functionally as well as a fixes to existing
tests.

== XFS status update for March 2011 ==

March saw the release of Linux 2.6.38, which included a sizable XFS update.
The most prominent new features of XFS in Linux 2.6.39 is support for the
FITRIM ioctl that allows discarding unused space on the filesystem
periodically, better handling of persistent preallocations especially on
NFS servers, and further scalability improvements in the buffer cache
and log code. In additions to that the release includes a wide range
of fixes and cleanups to the code base. The diff stat for XFS in the
Linux 2.6.39 release is:

57 files changed, 2964 insertions(+), 2528 deletions(-)

Which means the XFS code base actually had a minor growth in code size
this time around. In the second half of March the XFS development
tree got merged into Linus' tree for Linux 2.6.39. Linux 2.6.39 is going
to be a rather quiet release for XFS, mostly concentrating on settling
the large changes that went into the last releases and smaller cleanups.
The only user visible change will be that the delaylog option which
improves metadata performance and scalability is now turned on by default,
and a couple of fixes that make the realtime subvolume support usable
again.

On the user space side both xfsprogs and xfsdump saw new releases in March.
The xfsprogs 3.1.5 release contains various smaller updates to xfs_repair,
xfs_metadump and xfs_quota, as well as support for the new generic hole
punching in the falloc system call in the xfs_io tool. The xfsdump 3.0.5
release now supports up to 4 billion directory entries, has much better
performance for large dumps, and some improvements to the inventory code
and dumping of quota information, as well as long overdue updates to the
build system. The xfstests repository has seen various build system
improvements, better FIEMAP testing, falloc support for fsx and a few
cleanups.

== XFS status update for February 2011 ==

February saw the stabilization of the Linux 2.6.38 tree, with just two
small XFS fixes going into Linus' tree, and the XFS development tree
has been similarly quiet with just a few cleanups, and the delaylog option
propagated to the default operation mode. A few more patches for the 2.6.39
merge window have been posted and/or discussed on the mailing list, but February
was a rather quiet month in general.

On the user space side xfsprogs saw a few bug fixes, and a speedup for
phase2 of xfs_repair, xfsdump saw a bug fix and support for pruning the
inventory by session id, and xfstests saw it's usual stream of bug fixes
as well as two new test cases.

== XFS status update for January 2011 ==

On the 4th of January we saw the release of Linux 2.6.37, which contains a
large XFS update:

67 files changed, 1424 insertions(+), 1524 deletions(-)

User visible changes are the new XFS_IOC_ZERO_RANGE ioctl which allows
to convert already allocated space into unwritten extents that return
zeros on a read, and support for 32-bit wide project IDs. The other large
item are various changes to improve metadata scalability even further,
by changes to the the buffer cache, inode lookup and other parts of the
filesystem driver.

After that the XFS development tree for 2.6.38 was merged into mainline,
with an even larger set of changes. Notable items include support for the
FITRIM ioctl to discard unused space on SSDs and thinly provisioned storage
systems, a buffer LRU scheme to improve hit rates for metadata, an
overhaul of the log subsystem locking, dramatically improving scalability
in that area, and much smarter handling of preallocations, especially
for files closed and reopened frequently, e.g. by the NFS server.

User space development has been very quiet, with just a few fixes committed
to the xfstests repository, although various additional patches for xfsprogs
and xfstests that haven't been committed yet were discussed on the mailing list.

== XFS status update for December 2010 ==

The release process of the Linux 2.6.37 kernel with it's large XFS updates
was in it's final days in December, which explains why we only saw a single
one-liner regression fix for XFS in Linus' tree. The XFS development tree
finally saw some updates when the writeback updates and some small cleanups
to the allocator and log recovery code were merged, but the large metadata
scalability updates that have been posted to the list multiple times are
still missing. In addition to this on-going work the list also saw patches
that fix smaller issues, which are also still waiting to be merged.

On the userspace side xfsprogs and xfsdump development has been quit, with
no commits to either repository in December, although a large series of
updates to the metadump command has been reposted near the end of the month.
The xfstests repository saw a new regression test for a btrfs problem,
and various updates to existing tests.

== XFS status update for November 2010 ==

From looking at the kernel git commits November looked like a pretty
slow month with just two hand full fixes going into the release candidates
for Linux 2.6.37, and none at all going into the development tree.
But in this case git statistics didn't tell the whole story - there
was a lot of activity on patches for the next merge window on the list.
The focus in November was still at metadata scalability, with various
patchsets that improves parallel creates and unlinks again, and also
improves 8-way dbench throughput by 30%. In addition to that there
were patches to improve preallocation for NFS servers, to simplify
the writeback code, and to remove the XFS-internal percpu counters
for free space for the generic kernel percpu counters, which just needed
a small improvement.

On the user space side we saw the release of xfsprogs 3.1.4, which
contains various accumulated bug fixes and Debian packaging updates.
The xfsdump tree saw a large update to speed up restore by using
mmap for an internal database and remove the limitation of ~ 214
million directory entries per dump file. The xfstests test suite
saw three new testcases and various fixes, including support for the
hfsplus filesystem.

== XFS status update for October 2010 ==

Near the end of the month we finally saw the release of Linux 2.6.36.
Just a single fix made it into mainline in this month, showing that the
stabilization period before has worked very well.

Linux 2.6.36 has been another impressive release for XFS, seeing
various performance improvements in the new delayed logging code,
for direct I/O and the sync system call, a few bug fixes, and lots
of cleanups, resulting in a net removal of over 2000 lines of code:

89 files changed, 1998 insertions(+), 4279 deletions(-)

The merge window for Linux 2.6.37 opened just a few days after the
release of Linux 2.6.36 and already contains another large XFS update
at the end of October. Highlights of the XFS tree merged into 2.6.37-rc1
are another large set of metadata scalability patches, support for 32-bit
wide project IDs, and support for the new XFS_IOC_ZERO_RANGE ioctl,
which allows to punch a whole and convert it to an unwritten extent
in a single atomic operation.

The metadata scalability changes improve 8-way fs_mark of 50 million files
by over 15% and removal of those files by over 100%, with further
improvements expected by the next round of XFS metadata scalability
and VFS scalability improvements targeted at Linux 2.6.38.

On the user space side October was a rather quit month for xfsprogs, which
only saw the addition of 32-bit project ID handling, and a fix for
parsing the mount table in fsr when used together with disk encryption
tools. A few patches for xfsdump were posted on the list, but none
was applied, leaving the majority of the user space activity to
xfstests, which saw very active development. Various patches went
into xfstests to improve portability to filesystems with a limited
feature set, and to move more filters to generic code. In addition
various cleanups to test cases in test programs were applied.

== XFS status update for September 2010 ==

Mainline activity has been rather low in September while with only
two more fixes going into the 2.6.36 release candidates after the
large merge activity in August. Development for the next merge
window has been more active. The largest item was the inclusion
of the metadata scalability patch series, which provides very large
speedups for parallel metadata operations. In addition a new
ioctl to punch holes and convert the whole to an unwritten extent
was added and a small number of cleanups also made it into the tree.

Patches to add support for 32bit wide project ID identifiers and
using group and project quotas concurrently were posted to the list
and discussed but not yet included.

Userspace development has been rather quiet again, with a single fix
committed to xfsprogs and xfsdump each. The xfstests test suite grew
a new test case and received a few additional fixes. Last but not least
the [http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.html XFS Users Guide]
was updated with various factual corrections and spelling fixes.

== XFS status update for August 2010 ==

At the first of August we finally saw the release of Linux 2.6.35,
which includes a large XFS update. The most prominent feature in
Linux 2.6.35 is the new delayed logging code which provides massive
speedups for metadata-intensive workloads, but there has been
a large amount of other fixes and cleanups, leading to the following
diffstat:

67 files changed, 4426 insertions(+), 3835 deletions(-)

Given the early release of Linux 2.6.35 the merge window for the
next release fully fell into the month of August. The XFS updates
for Linux 2.6.36 include various additional performance improvements
in the delayed logging code, for direct I/O writes and for avoiding
synchronous transactions, as well as various fixed and large amount
of cleanups, including the removal of the remaining dead DMAPI
code.

On the userspace side we saw the 3.1.3 release of xfsprogs, which includes
various smaller fixes, support for the new XFS_IOC_ZERO_RANGE ioctl and
Debian packaging updates. The xfstests package saw one new test case
and a couple of smaller patches, and xfsdump has not seen any updates at
all.

The XMLified versions of the XFS users guide, training labs and filesystem
structure documentation are now available as on the fly generated html on
the xfs.org website and can be found at [[XFS_Papers_and_Documentation|Papers & Documentation]].

== XFS status update for July 2010 ==

July saw three more release candidates for the Linux 2.6.35 kernel, which
included a relatively large number of XFS updates. There were two security
fixes, a small one to prevent swapext to operate on write-only file
descriptors, and a much larger one to properly validate inode numbers
coming from NFS clients or userspace applications using the bulkstat or
the open-by-handle interfaces. In addition to that another relatively
large patch fixes the way inodes get reclaimed in the background, and
avoids inode caches growing out of bounds.

In the meantime the code for the Linux 2.6.36 got the last touches before
the expected opening of the merge window, by merging a few more last
minute fixes and cleanups. The most notable one is a patch series
that fixes in-memory corruption when concurrently accessing unwritten
extents using the in-kernel AIO code.

The userspace side was still quite slow, but some a bit more activity
than June. In xfsprogs the xfs_db code grew two bug fixes, as did
the xfs_io script. The xfstests package saw one new test cases and
various fixes to existing code. Last but not least a few patches
affecting the build system for all userspace tools were committed.

== XFS status update for June 2010 ==

The month of June saw a few important bug fixes for the Linux 2.6.35
release candidates. That includes ensuring that files used for the
swapext ioctl are writable to the user, and doing proper validation
of inodes coming from untrusted sources, such as NFS exporting and
the open by handle system calls. The main work however has been
focused on development for the Linux 2.6.36 merge window, including
merging various patches that have been out on the mainline list
for a long time. Highlights include further performance improvements
for sync heavy metadata workloads, stack space reduction in the
writeback path and improvements of the XFS tracing infrastructure.
Also after some discussion the remaining hooks for DMAPI are going
to be dropped in mainline. As a replacement a tree containing
full DMAPI support with a slightly cleaner XFS interaction will be
hosted by SGI.

On the userspace side June was a rather slow month, with no updates
to xfsprogs and xfsdump at all, and just one new test case and a cleanup
applied to xfstests.

== XFS status update for May 2010 ==

In May 2010 we saw the long awaited release of Linux 2.6.34, which includes
a large XFS update. The most important features appearing in 2.6.34 was the
new inode and quota flushing code, which leads to much better I/O patterns
for metadata-intensive workloads. Additionally support for synchronous NFS
exports has been improved to give much better performance, and performance
for the fsync, fdatasync and sync system calls has been improved slightly.
A bug when resizing extremely busy filesystems has been fixed, which required
extensive modification to the data structure used for looking up the
per-allocation group data. Last but not least there was a steady flow of
minor bug fixes and cleanups, leading to the following diffstat from
2.6.33 to 2.6.34:

86 files changed, 3209 insertions(+), 3178 deletions(-)

Meanwhile active development aimed at 2.6.35 merge progressed. The
major feature for this window is the merge of the delayed logging code,
which adds a new logging mode that dramatically reduces the bandwidth
required for log I/O. See the
[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/xfs-delayed-logging-design.txt;h=96d0df28bed323d5596fc051b0ffb96ed8e3c8df;hb=HEAD documentation] for details. Testers
for this new code are welcome.

In userland xfsprogs saw the long awaited 3.1.2 release, which can be
considered a bug fix release for xfs_repair, xfs_fsr and mkfs.xfs. After
the release a few more fixes were merged into the development tree.
The xfstests package saw various new tests, including many tests to
exercise the quota code, and a few fixes to existing tests.

== XFS status update for April 2010 ==

In April 2.6.34 still was in the release candidate phase, with
a hand full of XFS fixes making it into mainline. Development for
the 2.6.35 merge window went ahead full steam at the same time.

While a fair amount of patches hit the development tree these were
largely cleanups, with the real development activity happening on
the mailing list. There was another round of patches and following
discussion on the scalable busy extent tracking and delayed logging
features mentioned last month. They are expected to be merged in
May and queue up for the Linux 2.6.35 window. Last but not least
April saw a large number of XFS fixes backported to the 2.6.32 and
2.6.33 -stable series.

In user land xfsprogs has seen few but important updates, preparing
for a new release next month. The xfs_repair tool saw a fix to
correctly enable the lazy superblock counters on an existing
filesystem, and xfs_fsr saw updates to better deal with dynamic
attribute forks. Last but not a least a port to Debian GNU/kFreeBSD
got merged. The xfstests test suite saw two new test cases and various
smaller fixes.

== XFS status update for March 2010 ==

The merge window for Linux 2.6.34 closed in the first week of March,
with the important XFS features already landing in February. Not
surprisingly the XFS merge activity in March has been rather slow,
with only about a dozen bug fixes patches making it towards Linus'
tree in that time.

On the other hand active development for the 2.6.35 merge window has
been very active. Most importantly there was a lot of work on the
transaction and log subsystems. Starting with a large patchset to
clean up and refactor the transaction subsystem and introducing more
flexible I/O containers in the low-level logging code work is
progressing to a new, more efficient logging implementation. While
this preparatory work has already been merged in the development tree,
the actual delayed logging implementation still needs more work after
the initial public posting. The delayed logging implementation which
is very briefly modeled after the journaling mode in the ext3/4
and reiserfs filesystems allows to accumulated multiple asynchronous
transactions in memory instead of possibly writing them out
many times. Using the new delayed logging mechanism I/O bandwidth
used for the log decreases by orders of magnitude and performance
on metadata intensive workloads increases massively.

In addition to that a new version of the discard (aka TRIM) support
has been posted, this time entirely contained in kernel space
and without the need of a userspace utility to drive it. Last but
not least the usual steady stream of cleanups and bug fixes has not
ceased this month either.

Besides the usual flow of fixes and new test cases in the xfstests
test suite development on the userspace side has been rather slow.
Xfsprogs has only seen a single fix for SMP locking in xfs_repair
and support for building on Debian GNU/kFreeBSD, and xfsdump
has seen no commit at all.

== XFS status update for February 2010 ==

February saw the release of the Linux 2.6.33 kernel, which includes
a large XFS update. The biggest user-visible change in Linux 2.6.33
is that XFS now support the generic Linux trace event infrastructure,
which allows tracing lots of XFS behavior with a normal production
built kernel. Except for this Linux 2.6.33 has been mostly a bug-fix
release, fixing various user reported bugs in previous releases.
The total diffstat for XFS in Linux 2.6.33 looks like:

84 files changed, 3023 insertions(+), 3550 deletions(-)

In addition to that the merge window for Linux 2.6.34 opened and the
first merge of the XFS tree made it into Linus tree. Unlike Linux
2.6.33 this merge window includes major feature work. The most
important change for users is a new algorithm for inode and quota
writeback that leads to better I/O locality and improved metadata
performance. The second big change is a rewrite of the per-allocation
group data lookup which fixes a long-standing problem in the code
to grow a life filesystem and will also ease future filesystem
shrinking support. Not merged through the XFS tree, but of great
importance for embedded users is a new API that allows XFS to properly
flush cache lines on it's log and large directory buffers, making
XFS work properly on architectures with virtually indexed caches,
such as parisc and various arm and mips variants. Last but not
least there is an above average amount of cleanups that went into
Linus tree in this cycle.

There have been more patches on the mailing list that haven't made
it to Linus tree yet, including an optimized implementation of
fdatasync(2) and massive speedups for metadata workloads on
NFS exported XFS filesystems.

On the userspace side February has been a relatively quiet month.
Lead by xfstests only a moderate amount of fixes made it into
the respective trees.

== XFS status update for January 2010 ==

January saw additional release candidates of the Linux 2.6.33 kernel,
including a couple of bug fixes for XFS. In the meantime the XFS tree
has been growing a large number of patches destined for the Linux 2.6.34
merge window: a large rework of the handling of per-AG data, support for
the quota netlink interface, and better power saving behavior of the
XFS kernel threads, and of course various cleanups.

A large patch series to replace the current asynchronous inode writeback
with a new scheme that uses the delayed write buffers was posted to
the list. The new scheme, which allows archive better I/O locality by
dispatching meta-data I/O from a single place has been discussed
extensively and is expected to be merged in February.

On the userspace side January saw the 3.1.0 and 3.1.1 releases of xfsprogs,
as well as the 3.0.4 release of xfsdump. The biggest changes in xfsprogs
3.1.0 were optimizations in xfs_repair that lead to a much lower memory
usage, and optional use of the blkid library for filesystem detection
and retrieving storage topology information. The 3.1.1 release contained
various important bug fixes for these changes and a various improvements to
the build system. The major feature of xfsdump 3.0.4 were fixes for
time stamp handling on 64-bit systems.

The xfstests package also lots of activity including various new testcases
and an improved build system.

== XFS status update for December 2009 ==

December finally saw the long awaited release of Linux 2.6.32, which for
XFS is mostly a bug fix release, with the major changes being various
improvement to the sync path, including working around the expectation
from the grub boot loader where metadata is supposed to be after a sync()
system call. Together with a refactoring of the inode allocator this
gives a nice diffstat for this kernel release:

46 files changed, 767 insertions(+), 1048 deletions(-)

In the meantime development for the 2.6.33 has been going strong. The
new event tracing code that allows to observe the inner workings of XFS
in production systems has finally been merged, with another patch to
reduce the size of the tracing code by using new upstream kernel features
posted for review. Also a large patch series has been posted which
changes per-AG data to be looked up by a radix tree instead of the
existing array. This works around possible deadlocks and user after
free issues during growfs, and prepares for removing a global (shared)
lock from the free space allocators. In addition to that a wide range
of fixes has been posted and applied.

Work on the userspace packages has been just as busy. In mkfs.xfs the
lazy superblock counter feature has now been enabled by default for the
upcoming xfsprogs 3.1.0 release, which will require kernel 2.6.22 for
the default mkfs invocation. Also for mkfs.xfs as patch was posted
to correct the automatic detection of 4 kilobyte sector drivers which
are expected to show up in large quantities the real work soon. The
norepair mode in xfs_repair has been enhanced with additional freespace
btree correction checks from xfs_db and is now identical to xfs_check in
filesystem consistency checking coverage. A temporary file permission
problems has been fixed in xfs_fsr, and the libhandle library has been
fixed to better deal with symbolic links. In xfs_io a few commands
that were added years ago have finally been wired up to actually be
usable. And last but not least xfsdump saw a fix to the time stamp
handling in the backup format and some usability and documentation
improvements to xfsinvutil.

== XFS status update for November 2009 ==

November was a relatively slow month for XFS development. The XFS tree
that is destined for the Linux 2.6.33 merge window saw a few fixes and
cleanups applied to it, and few important fixes still made it into the
last Linux 2.6.32 release candidates. A few more patches including a
final version of the event tracing support for XFS were posted but not
reviewed yet.

On the userspace side there has been a fair amount of xfsprogs activity.
The repair speedup patches have finally been merged into the main development
branch and a couple of other fixes to the various utilities made it in, too.
The xfstests test suite saw another new regression test suite and a build
system fix up.

== XFS status update for October 2009 ==
In October we saw the Linux 2.6.32 merge window with a major XFS update.
This update includes a refactoring of the inode allocator which also
allows for speedups for very large filesystems, major sync fixes, updates
to the fsync and O_SYNC handling which merge the two code paths into a single
and more efficient one, a workaround for the VFS time stamp behavior,
and of course various smaller fixes. A couple of additional fixes have been
queued up for the next merge window.

On the userspace side there has been a healthy activity on xfsprogs: mkfs can
now discard unused sectors on SSDs and thinly provisioned storage devices and
use the more generic libblkid for topology information and filesystems detection
instead of the older libdisk, and the build system gained some updates to
make the source package generation simpler and shared for different package
types. A patch has been out to the list but yet committed to add symbol
versioning to the libhandle library to make future ABI additions easier.
The xfstests package only saw some minor activity with a new test case
and small build system fixes.

New minor releases of xfsprogs and xfsdump were tagged but not formally
released after additional discussion. Instead a new major xfsprogs release
is planned for next month.

== XFS status update for September 2009 ==

In September the Linux 2.6.31 kernel was finally released, including another
last minute XFS fix for the swapext (defragmentation) compat ioctl handler.
The final patch from 2.6.30 to 2.6.31 shows the following impressive diffstat
for XFS:

55 files changed, 1476 insertions(+), 2269 deletions(-)

The 2.6.32 merge window started with a large XFS merge that included changes
to the inode allocator, and a few smaller fixes. New versions of the sync
and time stamp fixes as well as the event tracing support have been posted
in September but not yet merged into the XFS development tree and/or mainline.

On the userspace side a large patch series to reduce the memory usage in
xfs_repair to acceptable levels was posted, but not yet merged. A new xfs_df
shell script to measure use of the on disk space was posted but not yet
merged pending some minor review comments and a missing man page. In addition
we saw the usual amount of smaller fixes and cleanups.

Also this month Felix Blyakher resigned from his post as XFS maintainer and handed off to Alex Elder.

== XFS status update for August 2009 ==

In August the Linux 2.6.31 kernel has still been in the release candidate
stage, but a couple of important XFS fixes made it in time for the release,
including a fix for the inode cache races with NFS workloads that have
plagued us for a long time.

The list saw various patches destined for the Linux 2.6.32 merge window,
including a merge of the fsync and O_SYNC handling code to address various
issues with the latter, a workaround for deficits in the timestamp handling
interface between the VFS and filesystems, a repost of the sync improvements
patch series and various smaller patches.

August also saw the minor 3.0.3 release of xfsprogs which collects smaller
fixes to the various tools and most importantly a fix to allow xfsprogs to
work again on SPARC and other strict alignment handling which regressed a
few releases ago. The xfstests repository saw a few new test cases and a
various small improvements.

== XFS status update for July 2009 ==

As a traditional summer vacation month July has not seen a lot of XFS
activity. The mainline 2.6.31 kernel made it to the 5th release candidate
but besides a few kernel-wide patches touching XFS the only activity were
two small patches fixing a bug in FIEMAP and working around writeback
performance problems in the VM.

A few more patches were posted to the list but haven't been merged yet.
Two big patch series deal with theoretically possible deadlocks due to
locks taken in reclaim contexts, which are now detected by lockdep.

The pace on the userspace side has been slow. There have been a couple
of fixes to xfs_repair and xfs_db, and xfstests grew a few more testcases.

== XFS status update for June 2009 ==

On June 9th we finally saw the release of Linux 2.6.30. For XFS
this release mostly contains the improved ENOSPC handling, but also
various smaller bugfixes and lots of cleanups. The code size of XFS
decreased again by 500 lines of code in this release.

The Linux 2.6.31 merge opened in the mid of the month and some big XFS
changes have been pushed: A removal of the quotaops
infrastructure which simplifies the quota implementation, the switch
from XFS's own Posix ACL implementation to the generic one shared
by various other filesystems which also supports in-memory caching of
ACLs and another incremental refactoring of the sync code.

A patch to better track dirty inodes and work around issues in the
way the VFS updates the access time stamp on inodes has been reposted
and discussed. Another patch to converting the existing XFS tracing
infrastructure to use the ftrace even tracer has been posted.

On the userspace side there have been a few updates to xfsprogs, including
some repair fixes and a new fallocate command for xfs_io. There were
major updates for xfstests: The existing aio-dio-regress testsuite has
been merged into xfstests, and various changes went into the tree to make
xfstests better suitable for use with other filesystems.

The attr and acl projects which have been traditionally been hosted
as part of the XFS userspace utilities have now been split into a separate
project maintained by Andreas Gruenbacher, who has been doing most of
the work on it, and moved to the Savannah hosting platform.

== XFS status update for May 2009 ==

In May Linux 2.6.30 was getting close to be released, and various
important XFS fixes made it during the latest release candidates.
In the meantime some big patch series to rework the sync code and
the inode allocator have been posted for the next merge window.

On the userspace side xfsprogs and xfsdump 3.0.1 were finally released,
quickly followed by 3.0.2 releases with updated Debian packaging.
After that various small patches that were held back made it into xfsprogs.
A patch to add the xfs_reno tool which allows to move inodes around to
fit into 32 bit inode number space has been posted which is also one
central aspect of future online shrinking support.

There has been major activity on xfstests including adding generic
filesystems support to allow running tests that aren't XFS-specific on
any Linux filesystems.

== XFS status update for April 2009 ==

In April development for Linux 2.6.30 was in full motion. A patchset to correct flushing of delayed allocations with near full filesystems has been committed in early April, as well as various smaller fixes. A patch series to improve the behavior of sys_sync has been posted but is waiting for VFS changes queued for Linux 2.6.31.

On the userspace side xfsprogs and xfsdump 3.0.1 have managed to split their release dates into May again after a lot of last-minute build system updates.

== XFS status update for March 2009 ==

Linux 2.6.29 has been released which includes major XFS updates like the
new generic btree code, a fully functional 32bit compat ioctl implementation
and the new combined XFS and Linux inode. (See previous status reports
for more details). A patch series to improve correctness and performance
has been posted but not yet applied. Various minor fixes and cleanups
have been sent to Linus for 2.6.30 which looks like it will be a minor
release for XFS after the big churn in 2.6.29.

On userspace a lot of time has been spent on fixing and improving the
build system shared by the various XFS utilities as well as various smaller
improvements leading to the xfsprogs and xfsdump 3.0.1 releases which are
still outstanding.

== XFS status update for February 2009 ==

In February various smaller fixes have been sent to Linus for 2.6.29,
including a revert of the faster vmap APIs which don't seem to be quite
ready yet on the VM side. At the same time various patches have been
queued up for 2.6.30, with another big batch pending. There also has
been a repost of the CRC patch series, including support for a new,
larger inode core.

SGI released various bits of work in progress from former employees
that will be extremely helpful for the future development of XFS,
thanks a lot to Mark Goodwin for making this happen.

On the userspace side the long awaited 3.0.0 releases of xfsprogs and
xfsdump finally happened early in the month, accompanied by a 2.2.9
release of the dmapi userspace. There have been some issues with packaging
so a new minor release might follow soon.

The xfs_irecover tool has been relicensed so that it can be merged into
the GPLv2 codebase of xfsprogs, but the actual integration work hasn't
happened yet.

Important bits of XFS documentation that have been available on the XFS
website in PDF form have been released in the document source form under
the Creative Commons license so that they can be updated as a community
effort, and checked into a public git tree.

== XFS status update for January 2009 ==

January has been an extremely busy month on the userspace front. Many
smaller and medium updates went into xfsprogs, xfstests and to a lesser
extent xfsdump. xfsprogs and xfsdump are ramping up for getting a 3.0.0
release out in early February which will include the first major re-sync
with the kernel code in libxfs, a cleanup of the exported library interfaces
and the move of two tools (xfs_fsr and xfs_estimate) from the xfsdump
package to xfsprogs. After this the xfsprogs package will contain all
tools that use internal libxfs interfaces which fortunately equates to those
needed for normal administration. The xfsdump package now only contains
the xfsdump/xfsrestore tools needed for backing up and restoring XFS
filesystems. In addition it grew a fix to support dump/restore on systems
with a 64k page size. A large number of acl/attr package patches was
posted to the list, but pending a possible split of these packages from the
XFS project these weren't processed yet.

On the kernel side the big excitement in January was an in-memory corruption
introduced in the btree refactoring which hit people running 32bit platforms
without support for large block devices. This issue was fixed and pushed
to the 2.6.29 development tree after a long collaborative debugging effort
at linux.conf.au. Besides that about a dozen minor fixes were pushed to
2.6.29 and the first batch of misc patches for the 2.6.30 release cycle
was sent out.

At the end of December the SGI group in Melbourne which the previous
XFS maintainer and some other developers worked for has been closed down
and they will be missed greatly. As a result maintainership has been passed
on in a way that has been slightly controversial in the community, and the
first patchset of work in progress in Melbourne have been posted to the list
to be picked up by others.

The xfs.org wiki has gotten a little facelift on it's front page making it
a lot easier to read.

== XFS status update for December 2008 ==

On Christmas Eve the 2.6.28 mainline kernel was release, with only minor XFS
bug fixes over 2.6.27.

On the development side December has been busy but unspectacular month.
All lot of misc fixes and improvements have been sent out, tested and committed
especially on the user land side.

== XFS status update for November 2008 ==

The mainline kernel is now at 2.6.28-rc6 and includes a small number of
XFS fixes. There have been no updates to the XFS development tree during
November. Without new regressions that large number of changes that
missed 2.6.28 has thus stabilized to be ready for 2.6.29. In the meantime
kernel-side development has been slow, with the only major patch set
being a wide number of fixes to the compatibility for 32 bit ioctls on
a 64 bit kernel.

In the meantime there has been a large number of commits to the user space
tree, which mostly consist of smaller fixes. xfsprogs is getting close
to have the 3.0.0 release which will be the first full resync with the
kernel sources since the year 2005.

== XFS status update for October 2008 ==

Linux 2.6.27 released with all the bits covered in last month's report. It
did however miss two important fixes for regressions that a few people hit.
2.6.27.3 or later are recommended for use with XFS.

In the meantime the generic btree implementation, the sync reorganization
and after a lot of merge pain the XFS and VFS inode unification hit the
development tree during the time allocated for the merge window. No XFS
updates other than the two regression fixes also in 2.6.27.3 have made it
into mainline as of 2.6.28-rc3.

The only new feature on the list in October is support for the fiemap
interface that has been added to the VFS during the 2.6.28 merge window.
However there was lot of patch traffic consisting of fixes and respun
versions of previously known patches. There still is a large backlog of
patches on the list that is not applied to the development tree yet.

== XFS status update for September 2008 ==

With Linux 2.6.27 still not released but only making slow progress from 2.6.27-rc5 to 2.6.27-rc8 XFS changes in mainline have been minimal in September with only about half a dozen bug fixes patches.

In the meantime the generic btree patch set has been committed to the development tree, but not many other updates yet. On the user space side xfsprogs 2.10.1 has been released on September 5th with a number of important bug fixes. Following the release of xfsprogs 2.10.1 open season for development of the user space code has started. The first full update of the shared kernel / user space code in libxfs since 2005 has been committed. In addition to that the number of headers installed for the regular devel package has been reduced to the required minimum and support for checking the source code for endianess errors using sparse has been added.

The patch sets to unify the XFS and Linux inode structures, and rewrite various bits of the sync code have seen various iterations on the XFS list, but haven't been committed yet. A first set of patches implementing CRCs for various metadata structures has been posted to the list.

== XFS status update for August 2008 ==

With the 2.6.27-rc5 release the 2.6.27 cycle is nearing it's end. The major XFS feature in 2.6.27-rc5 is support for case-insensitive file names. At this point it is still limited to 7bit ASCII file names, with updates for utf8 file names expected to follow later. In addition to that 2.6.27-rc5 fixes a long-standing problem with non-EABI arm compiler which pack some XFS data structures wrongly. Besides this 2.6.27-rc5 also contains various cleanups, most notably the removal of the last bhv_vnode_t instances, and most uses of semaphores. As usual the diffstat for XFS from 2.6.26 to 2.6.26-rc5 is negative:

100 files changed, 3819 insertions(+), 4409 deletions(-)

On the user space front a new minor xfsprogs version is about to be released containing various fixes including the user space part of arm packing fix.

Work in progress on the XFS mailing list are a large patch set to unify the alloc, inobt and bmap btree implementation into a single that supports arbitrarily pluggable key and record formats. These btree changes are the first major preparation for adding CRC checks to all metadata structures in XFS, and an even larger patch set to unify the XFS and Linux inode structures, and perform all inode write back from the btree uses instead of an inode cache in XFS.

== Updates before 2008 ==

News up to 2007 can be found on a separate page: [[OLD_News]]

XFS Companies

2012-02-03T19:59:44Z

Ckujau: 404 fixed

= These are companies that either use XFS or have a product that utilizes XFS . =

Info gathered from: [http://oss.sgi.com/projects/xfs/users.html XFS Users] on [http://oss.sgi.com/ oss.sgi.com]

== [http://www.dell.com/ Dell's HPC NFS Storage Solution] ==

"The Dell NFS Storage Solution (NSS) is a unique new storage solution providing cost-effective NFS storage as an appliance. Designed to scale from 20 TB installations up to 80 TB of usable space, the NSS is delivered as a fully configured, ready-to-go storage solution and is available with full hardware and software support from Dell. ... XFS was chosen for the NSS because XFS is capable of scaling beyond 16 TB and provides good performance for a broad range of applications."

More information is available in [http://i.dell.com/sites/content/business/solutions/hpcc/en/Documents/Dell-NSS-NFS-Storage-solution-final.pdf this solution guide].

== [http://www.kernel.org/ The Linux Kernel Archives] ==

"A bit more than a year ago (as of October 2008) kernel.org, in an ever increasing need to squeeze more performance out of it's machines, made the leap of migrating the primary mirror machines (mirrors.kernel.org) to XFS. We site a number of reasons including fscking 5.5T of disk is long and painful, we were hitting various cache issues, and we were seeking better performance out of our file system."

"After initial tests looked positive we made the jump, and have been quite happy with the results. With an instant increase in performance and throughput, as well as the worst xfs_check we've ever seen taking 10 minutes, we were quite happy. Subsequently we've moved all primary mirroring file-systems to XFS, including www.kernel.org , and mirrors.kernel.org. With an average constant movement of about 400mbps around the world, and with peaks into the 3.1gbps range serving thousands of users simultaneously it's been a file system that has taken the brunt we can throw at it and held up spectacularly."

== [http://www.sdss.org/ The Sloan Digital Sky Survey] ==

"The Sloan Digital Sky Survey is an ambitious effort to map one-quarter of the sky at optical and very-near infrared wavelengths and take spectra of 1 million extra-galactic objects. The estimated amount of data that will be acquired over the 5 year lifespan of the project is 15TB, however, the total amount of storage space required for object informational databases, corrected frames, and reduced spectra will be several factors more than this. The goal is to have all the data online and available to the collaborators at all times. To accomplish this goal we are using commodity, off the shelf (COTS) Intel servers with EIDE disks configured as RAID50 arrays using XFS. Currently, 14 machines are in production accounting for over 18TB. By the scheduled end of the survey in 2005, 50TB of XFS disks will be online serving SDSS data to collaborators and the public."

"For complete details and status of the project please see [http://www.sdss.org/ http://www.sdss.org]. For details of the storage systems, see the [http://web.archive.org/web/20100228003734/http://home.fnal.gov/~yocum/storageServerTechnicalNote.html SDSS Storage Server Technical Note] (Dan Yocum, Fermi National Lab, November 9 2001, archived)."

== [http://www-d0.fnal.gov/ The DØ Experiment at Fermilab] ==

"At the DØ experiment at the Fermi National Accelerator Laboratory we have a ~150 node cluster of desktop machines all using the SGI-patched kernel. Every large disk (>40Gb) or disk array in the cluster uses XFS including 4x640Gb disk servers and several 60-120Gb disks/arrays. Originally we chose reiserfs as our journaling filesystem, however, this was a disaster. We need to export these disks via NFS and this seemed perpetually broken in 2.4 series kernels. We switched to XFS and have been very happy. The only inconvenience is that it is not included in the standard kernel. The SGI guys are very prompt in their support of new kernels, but it is still an extra step which should not be necessary."

== [http://www.ciprico.com/pDiMeda.shtml Ciprico DiMeda NAS Solutions] ==

"The Ciprico DiMeda line of Network Attached Storage solutions combine the ease of connectivity of NAS with the SAN like performance levels required for digital media applications. The DiMeda 3600 provides high availability and high performance through dual NAS servers and redundant, scalable Fibre Channel RAID storage. The DiMeda 1700 provides high performance files services at a low price by using the latest Serial ATA RAID technology. All DiMeda systems are based on Linux and use XFS as the filesystem. We tested a number of filesystem alternatives and XFS was chosen because it provided the highest performance in digital media applications and the journaling feature ensures rapid failover in our dual node fault tolerant configurations."

== [http://www.quantum.com/Products/NAS+Servers/Guardian+14000/Default.htm The Quantum Guardian™ 14000] ==

"The Quantum Guardian™ 14000, the latest Network Attached Storage (NAS) solution from Quantum, delivers 1.4TB of enterprise-class storage for less than $25,000. The Guardian 14000 is a Linux-based device which utilizes XFS to provide a highly reliable journaling filesystem with simultaneous support for Windows, UNIX, Linux and Macintosh environments. As dedicated appliance optimized for fast, reliable file sharing, the Guardian 14000 combines the simplicity of NAS with a robust feature set designed for the most demanding enterprise environments. Support for tools such as Active Directory Service (ADS), UNIX Network Information Service (NIS) and Simple Network Management Protocol (SNMP) provides ease of management and seamless integration. Hardware redundancy, Snapshots and StorageCare™ on-site service ensure security for business-critical data."

== [http://www.bigstorage.com/products_approach_overview.html BigStorage K2~NAS] ==

"At BigStorage we pride ourselves on tailoring our NAS systems to meet our customer's needs, with the help of XFS we are able to provide them with the most reliable Journaling Filesystem technology available. Our open systems approach, which allows for cross-platform integration, gives our customers the flexibility to grow with their data requirements. In addition, BigStorage offers a variety of other features including total hardware redundancy, snapshotting, replication and backups directly from the unit. All of our products include BigStorageï¿½s 24/7 LiveResponse™ support. With LiveResponse™, we keep our team of experienced technical experts on call 24 hours a day, every day, to ensure that your storage investment remains online, all the time."

== [http://www.echostar.com Echostar DishPVR 721] ==

"Echostar uses the XFS filesystem for its latest generation of satellite receivers, the DP721. Echostar chose XFS for its performance, stability and unique set of features."

"XFS allowed us to meet a demanding requirement of recording two mpeg2 streams to the internal hard drive while simultaneously viewing a third pre-recorded stream. In addition, XFS allowed us to withstand unexpected power loss without filesystem corruption or user interaction."

"We tested several other filesystems, but XFS emerged as the clear winner."

== [http://www.sun.com/hardware/serverappliances/raq550/ Sun Cobalt RaQ™ 550] ==

From the [http://www.sun.com/hardware/serverappliances/raq550/features.html features] page:

"XFS is a journaling file system capable of quick fail over recovery after unexpected interruptions. XFS is an important feature for mission-critical applications as it ensures data integrity and dramatically reduces startup time by avoiding FSCK delay."

== [http://pingu.salk.edu/ Center for Cytometry and Molecular Imaging at the Salk Institute] ==

"I run the Center for Cytometry and Molecular Imaging at the Salk Institute in La Jolla, CA. We're a core facility for the Institute, offering flow cytometry, basic and deconvolution microscopy, phosphorimaging (radioactivity imaging) and fluorescent imaging."

"I'm currently in the process of migrating our data server to Linux/XFS. Our web server currently uses Linux/XFS. We have about 60 Gb on the data server which has a 100Gb SCSI RAID 5 array. This is a bit restrictive for our microscopists so in order that they can put more data online, I'm adding another machine, also running Linux/XFS, with about 420 Gb of IDE-RAID5, based on Adaptec controllers...."

"Servers are configured with quota and run Samba, NFS, and Netatalk for connectivity to the mixed bag of computers we have around here. I use the CVS XFS tree most of the time. I have not seen any problems in the several months I have been testing."

== [http://coltex.nl/ Coltex Retail Group BV] ==

"Coltex Retail group BV in the Netherlands uses Red Hat Linux with XFS for their main database server which collects the data from over 240 clothing retail stores throughout the Netherlands. Coltex depends on the availability of the server for over 100 hundred employees in the main office for retrieval of logistical and sales figures. The database size is roughly 10GB large containing both historical and current data."

"The entire production and logistical system depends on the availability of the system and downtime would mean a significant financial penalty. The speed and reliability of the XFS filesystem which has a proven track record and mature tools to go with it is fundamental to the availability of the system."

"XFS has saved us a lot of time during testing and implementation. A long filesystems check is no longer needed when bad things happen when they do. The increased speed of our database system which is based on Progress 9.1C is also a nice benefit to this filesystem."

== [http://www.dkp.com/ DKP Effects] ==

"We're a 3D computer graphics/post-production house. We've currently got four fileservers using XFS under Linux online - three 350GB servers and one 800GB server. The servers are under fairly heavy load - network load to and from the dual NICs on the box is basically maxed out 18 hours a day - and we do have occasional lockups and drive failures. Thanks to Linux SW RAID5 and XFS, though, we haven't had any data loss, or significant down time."

== [http://www.epigenomics.com/ Epigenomics] ==

"We currently have several IDE-to-SCSI-RAID systems with XFS in production. The largest has a capacity of 1.5TB, the other 2 have 430GB each."

"Data stored on these filesystems is on the one hand "normal" home directories and corporate documents and on the other hand scientific data for our laboratory and IT department."

== [http://www.incyte.com/ Incyte Genomics] ==

"I'm currently in the process of slowly converting 21 clusters totaling 2300+ processors over to XFS."

"These machines are running a fairly stock RH7.1+XFS. The application is our own custom scheduler for doing genomic research. We have one of the worlds largest sequencing labs which generates a tremendous amount of raw data. Vast amounts of CPU cycles must be applied to it to turn it into useful data we can then sell access to."

"Currently, a minority of these machines are running XFS, but as I can get downtime on the clusters I am upgrading them to 7.1+XFS. When I'm done, it'll be about 10TB of XFS goodness... across 9G disks mostly."

== [http://www.monmouth.edu/ Monmouth University] ==

"We've replaced our NetApp filer (80GB, $40,000). NetApp ONTAP software [runs on NetApp filers] is basically an NFS and CIFS server with their own proprietary filesystem. We were quickly running out of space and our annual budget almost depleted. What were we to do?"

"With an off-the-shelf Dell 4400 series server and 300GB of disks ($8,000 total). We were able to run Linux and Samba to emulate a NetApp filer."

"XFS allowed us to manage 300GB of data with absolutely no downtime (now going on 79 days) since implementation. Gone are the days of fearing the fsck of 300GB."

== [http://www.astro.wisc.edu The University of Wisconsin Astronomy Department] ==

"At the University of Wisconsin Astronomy Department we have been using Linux XFS since the first release. We currently have 31 Linux boxes running XFS on all filesystems with about 2.6 TB of disk space on these machines. We use XFS primarily on our data reduction systems, but we also use it on our web server and on one of the remote observing machines at the WIYN 3.5m Telescope at Kitt Peak (http://www.noao.edu/wiyn/wiyn.html)."

"We will likely be using Linux XFS at least in part on the GLIMPSE program (http://www.astro.wisc.edu/sirtf/) which will likely require several TB of disk space to process the data."

== [http://www.amoa.org/ The Austin Museum of Art] ==

"The Austin Museum of Art has two file servers running RedHat 7.2_XFS upgraded from RedHat 7.1_XFS. Our webserver runs Domino on top of RedHat 7.3_XFS and we're getting about 70% better performance than the Domino server running on Windows 2000 Server. We're moving our workstations away from Windows and Microsoft Office to an LTSP server running on RedHat 7.3_XFS.

"We've become solely dependent on XFS for all of our data systems."

== [http://www.tecmath.com/ tecmath AG] ==

"We use a production server with a 270 GB RAID 5 (hardware) disk array. It is based on a Suse 7.2 distribution, but with a standard 2.4.12 kernel with XFS and LVM patches. The server provides NFS to 8 Unix clients as well as Samba to about 80 PCs. The machine also runs Bind 9, Apache, Exim, DHCP, POP3, MySQL. I have tried out different configurations with ReiserFS, but I didn't manage to find a stable configuration with respect to NFS. Since I converted all disks to XFS some 3 months ago, we never had any filesystem-related problems."

== [http://www.theiqgroup.com/ The IQ Group] ==

"Here at the IQ Group, Inc. we use XFS for all our production and development servers."

"Our OS of choice is Slackware Linux 8.0. Our hardware of choice is Dell and VALinux servers."

"As for applications, we run the standard Unix/Linux apps like Sendmail, Apache, BIND, DHCP, iptables, etc.; as well as Oracle 9i and Arkeia."

"We've been running XFS across the board for about 3 months now without a hitch (so far)."

"Size-wise, our biggest server is about 40 GB, but that will be increasing substantially in the near future."

"Our production servers are collocated so a journaled FS was a must. Reboots are quick and no human interaction is required like with a bad fsck on ext2. Additionally, our database servers gain additional integrity and robustness."

"We originally chose XFS over ReiserFS and ext3 because of it's age (it's been in production on SGI boxes for probably longer than all the other journaling FS's combined) and it's speed appeared comparable as well."

== [http://www.artsit.usyd.edu.au Arts IT Unit, Sydney University] ==

"I've got XFS on a 'production' file server. The machine could have up to 500 people logged in, but typically less than 200. Most are Mac users, connected via NetAtalk for 'personal files', although there are shared areas for admin units. Probably about 30-40 windows users. (Samba) It's the file server for an Academic faculty at a University."

"Hardware RAID, via Mylex dual channel controller with 4 drives, Intel Tupelo MB, Intel 'SC5000' server chassis with redundant power and hot-swap scsi bays. The system boots off a non RAID single 9gb UW-scsi drive."

"Only system 'crash' was caused by some one accidentally unplugging it, just before we put it into production. It was back in full operation within 5 minutes. Without journaling, the fsck would have taken well over an hour. In day to day use it has run well."

== [http://structbio.vanderbilt.edu/comp/ Vanderbilt University Center for Structural Biology] ==

"I run a high-performance computing center for Structural Biology research at Vanderbilt University. We use XFS extensively, and have been since the late prerelease versions. I've had nothing but good experiences with it."

"We began using XFS in our search for a good solution for our RAID fileservers. We had such good experiences with it on these systems that we've begun putting it on the root/usr/var partitions of every Linux system we run here. I even have it on my laptop these days. XFS in combination with the 2.4 NFS3 implementation performs very well for us, and we have great uptimes on these systems (Our 750GB ArenaII setup is at 143 days right now)."

"All told, we've got about 1.2TB of XFS filesystems spinning right now. It's spread out across maybe a dozen or so filesystems and will continue to increase as we are growing fast and that's all we use now. Next up is putting it on our 17-node Linux cluster, which will bring that up to 1.5TB spread across 30 filesystems."

"I, for one, would LOVE to see XFS make it into the kernel tree. From my perspectives, it's one of the best things to happen to Linux in the 7 years I've been using/administering it."

==== 2008 Update ====

"We've since moved our main home directories to a proprietary NAS, but continue to use XFS on 10TB of LVM storage for doing backup-to-disk from the same NAS"

== [http://www-cdf.fnal.gov/ CDF Experiment at Fermi National Lab] ==

CDF, an elementary particle physics experiment at Fermi National Lab, is using XFS for all our cache disks.

The usage model is that we have a PB tape archive (2 STK silos) as permanent storage. In front of this archive we are deploying a roughly 100TB disk cache system. The cache is made up of 50 2TB file server based on cheap commodity hardware (3ware based hardware raid using IDE drives). The data is then processed by a cluster of 300 Dual CPU Linux PC's. The cache software is dCache, a DESY/FNAL product.

The whole system is used by more than 300 active users from all over the world for batch processing for their physics data analysis.

== [http://www.get2chip.com Get2Chip, Inc.] ==

"We are using XFS on 3 production file servers with approximately 1.5T of data. Quite impressive especially when we had a power outage and all three servers shutdown. All servers came back up in minutes with no problems! We are looking at creating two more servers that would manage 2+ TB of data store."

== [http://www.lando.co.za Lando International Group Technologies] ==

Lando International Group Technologies is the home of:

* [www.lando.co.za Lanndo Technologies Africa (Pty) Ltd] - Internet Service Provider
* [www.lbsd.net Linux Based Systems Design] (Article 21). Not-For-Profit company established to provide free Linux distributions and programs.
* Cell Park South Africa (Pty) Ltd. RSA Pat Appln 2001/10406. Collecting parking fees by means of cell phone SMS or voice.
* Read Plus Education (Pty) Ltd. Software based reading skills training and testing for ages 4 to 100.
* Mobivan. Mobile office including Internet access, fax, copying, printing, telephone, collection and delivery services, legal services, pre-paid phone and electricity services, bill payment email, secretarial services, training facilities and management services.
* Lando International Marketing Agency. Direct marketing services, design and supply of promotional material, consulting, sourcing of capital and other funding.
* Illico. Software development and systems analysis on most platforms.

"Throughout these companies, we use the XFS filesystem with [http://idms.lbsd.net IDMS Linux] on high-end Intel servers, with an average of 100 GB storage each. XFS stores our customer and user data, including credit card details, mail, routing tables, etc.. We have not had one problem since the release of the first XFS patch."

== [http://www.fcb-wilkens.com Foote, Cone, & Belding] ==

"We are an advertisement company in Germany, and the use of the XFS filesystem is a story of success for us. In our Hamburg office, we have two file servers having a 420 Gig RAID in XFS format serving (almost) all our data to about 180 Macs and about 30 PCs using Samba and Netatalk. Some of the data is used in our offices in Frankfurt and Berlin, and in fact the Berlin office is just getting it's own 250 Gig fileserver (using XFS) right now."

"The general success with XFS has led us to switch over all our Linux servers to run on XFS as well (with the exception of two systems that are tied to tight specifications configuration wise). XFS, even the old 1.0 version, has happily taken on various abuse - broken SCSI controllers, broken RAID systems."

== [http://www.moving-picture.co.uk/ Moving Picture Company] ==

"We here at MPC use XFS/RedHat 7.2 on all of our graphics-workstations and file-servers. More info can be found in an [http://www.linuxuser.co.uk/articles/issue20/lu20-Linux_at_work-In_the_picture.pdf article] LinuxUser magazine did on us recently."

== [http://www.coremetrics.com/ Coremetrics, Inc.] ==

"We are currently using XFS for 25+ production web-servers, ~900GB Oracle db servers, with potentially 15+ more servers by mid 2003, with ~900GB+ databases. All XFS installed."

"Also, our dev environment, except for the Sun boxes which all are being migrated to X86 in the aforementioned server additions, plus the dev Sun boxes as well, are all x86 dual proc servers running Oracle, application servers, or web services as needed. All servers run XFS from images we've got on our SystemImager servers."

"All production back-end servers are connected via FC1 or FC2 to a SAN containing ~13TB of raw storage, which, will soon be converted from VxFS to XFS with the migration of Oracle to our x86 platforms."

== [http://evolt.org Evolt.org] ==

"evolt.org, a world community for web developers promoting the mutual free exchange of ideas, skills and experiences, has had a great deal of success using XFS. Our primary webserver which serves 100K hosts/month, primary Oracle database with ~25Gb of data, and free member hosting for 1000 users haven't had a minute of downtime since XFS has been installed. Performance has been spectacular and maintenance a breeze."

<font size="-1"> ''All testimonials on this page represent the views of the submitters, and references to other products and companies should not be construed as an endorsement by either the organizations profiled, or by SGI. All trademarks (r) their respective owners.'' </font>

XFS Papers and Documentation

2012-01-30T03:47:51Z

Ckujau: s/XFSÂ/XFS/

=== Primary XFS Documentation ===

The XFS documentation started by SGI has been converted to docbook/[https://fedorahosted.org/publican/ Publican] format. The material is suitable for experienced users as well as developers and support staff. The XML source is available in a [http://git.kernel.org/?p=fs/xfs/xfsdocs-xml-dev.git;a=summary git repository] and builds of the documentation are available here:

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.html XFS User Guide]

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html XFS File System Structure]
** [http://sites.google.com/site/kandamotohiro/xfs Japanese translation] is also available.

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Labs/tmp/en-US/html/index.html XFS Training Labs]

* (Original versions of this material are still available at [http://oss.sgi.com/projects/xfs/training/index.html XFS Overview and Internals (html)] and [http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf XFS Filesystem Structure (pdf)]

The format of <tt>/proc/fs/xfs/stat</tt> also has been documented:
* [[Runtime_Stats|Runtime_Stats]]

=== Papers, Presentations, Etc ===

At the linux.conf.au 2012 event, Dave Chinner presented a talk on filesystem metadata scalability:

* ''XFS - Recent and Future Adventures in Filesystem Scalability'' [[http://www.youtube.com/watch?v=FegjLbCnoBw Video]] [[http://xfs.org/images/d/d1/Xfs-scalability-lca2012.pdf Presentation Slides]]

The October 2009 issue of the USENIX ;login: magazine published an article about XFS targeted at system administrators:

* ''XFS: The big storage file system for Linux'' [[http://oss.sgi.com/projects/xfs/papers/hellwig.pdf pdf]]

At the Ottawa Linux Symposium (July 2006), Dave Chinner presented a paper on filesystem scalability in Linux 2.6 kernels:

* ''High Bandwidth Filesystems on Large Systems'' (July 2006) [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf paper]] [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-presentation.pdf presentation]]

At linux.conf.au 2008 Dave Chinner gave a presentation about xfs_repair that he co-authored with Barry Naujok:

* Fixing XFS Filesystems Faster [[http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf pdf]]

In July 2006, SGI storage marketing updated the XFS datasheet:

* ''Open Source XFS for Linux'' [[http://oss.sgi.com/projects/xfs/datasheet.pdf pdf]]

At UKUUG 2003, Christoph Hellwig presented a talk on XFS:

* ''XFS for Linux'' (July 2003) [[http://oss.sgi.com/projects/xfs/papers/ukuug2003.pdf pdf]] [[http://verein.lst.de/~hch/talks/ukuug2003/ html]]

Originally published in Proceedings of the FREENIX Track: 2002 Usenix Annual Technical Conference:

* ''Filesystem Performance and Scalability in Linux 2.4.17'' (June 2002) [[http://oss.sgi.com/projects/xfs/papers/filesystem-perf-tm.pdf pdf]]

At the Ottawa Linux Symposium, an updated presentation on porting XFS to Linux was given:

* ''Porting XFS to Linux'' (July 2000) [[http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm html]]

At the Atlanta Linux Showcase, SGI presented the following paper on the port of XFS to Linux:

* ''Porting the SGI XFS File System to Linux'' (October 1999) [[http://oss.sgi.com/projects/xfs/papers/als/als.ps ps]] [[http://oss.sgi.com/projects/xfs/papers/als/als.pdf pdf]]

At the 6th Linux Kongress & the Linux Storage Management Workshop (LSMW) in Germany in September, 1999, SGI had a few presentations including the following:

* ''SGI's port of XFS to Linux'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/linux_kongress/index.htm html]]
* ''Overview of DMF'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/DMF-over/index.htm html]]

At the LinuxWorld Conference & Expo in August 1999, SGI published:

* ''An Open Source XFS data sheet'' (August 1999) [[http://oss.sgi.com/projects/xfs/papers/xfs_GPL.pdf pdf]]

From the 1996 USENIX conference:

* ''An XFS white paper'' [[http://oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html html]]

=== Other historical articles, press-releases, etc ===

* IBM's ''Advanced Filesystem Implementor's Guide'' has a chapter ''Introducing XFS'' [[http://www-106.ibm.com/developerworks/library/l-fs9.html html]]

* An editorial titled ''Tired of fscking? Try a journaling filesystem!'', Freshmeat (February 2001) [[http://freshmeat.net/articles/view/212/ html]]

* ''Who give a fsck about filesystems'' provides an overview of the Linux 2.4 filesystems [[http://www.linuxuser.co.uk/articles/issue6/lu6-All_you_need_to_know_about-Filesystems.pdf html]]

* ''Journal File Systems'' in issue 55 of ''Linux Gazette'' provides a comparison of journaled filesystems.

* The original XFS beta release announcement was published in ''Linux Today'' (September 2000) [[http://linuxtoday.com/news_story.php3?ltsn=2000-09-26-017-04-OS-SW html]]

* ''XFS: It's worth the wait'' was published on ''EarthWeb'' (July 2000) [[http://networking.earthweb.com/netos/oslin/article/0,,12284_623661,00.html html]]

* An ''IRIX-XFS data sheet'' (July 1999) [[http://oss.sgi.com/projects/xfs/papers/IRIX_xfs_data_sheet.pdf pdf]]

* The ''Getting Started with XFS'' book (1994) [[http://oss.sgi.com/projects/xfs/papers/getting_started_with_xfs.pdf pdf]]

* Original ''XFS design documents'' (1993) ([http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_ps/ ps], [http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/ pdf])

Ideas for XFS

2012-01-27T00:29:23Z

Ckujau: url fixed, bogus article link removed

= Future Directions for XFS =

Dave Chinner ideas:

* [[Improving inode Caching]]

* [[Improving Metadata Performance By Reducing Journal Overhead]]

* [[Reliable Detection and Repair of Metadata Corruption]]

Other ideas:

* [[Splitting project quota support from group quota support]]

* [[Assigning project quota to a linux container]]

* [[Support discarding of unused sectors]] (status: completed)

* Superblock flag for when 64-bit inodes are present (see [http://oss.sgi.com/pipermail/xfs/2009-May/041379.html xfs: regarding the inode64 mount option])

* Wishlist: Please integrate ''xfs_irecover'' or provide [http://www.who.is.free.fr/wiki/doku.php?id=recover inode recovery feature]

XFS FAQ

2012-01-27T00:26:22Z

Ckujau: url fixed, bogus article links removed

Info from: [http://oss.sgi.com/projects/xfs/faq.html main XFS faq at SGI]

Many thanks to earlier maintainers of this document - Thomas Graichen and Seth Mos.

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

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''.

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

Andreas Gruenbacher maintains the Extended Attribute and POSIX ACL documentation for Linux at http://acl.bestbits.at/

The '''acl(5)''' manual page is also quite extensive.

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

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.

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

Linux native filesystem (83).

== Q: What mount options does XFS have? ==

There are a number of mount options influencing XFS filesystems - refer to the '''mount(8)''' manual page or the documentation in the kernel source tree itself ([http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/xfs.txt;hb=HEAD Documentation/filesystems/xfs.txt])

== Q: Is there any relation between the XFS utilities and the kernel version? ==

No, there is no relation. Newer utilities tend to mainly have fixes and checks the previous versions might not have. New features are also added in a backward compatible way - if they are enabled via mkfs, an incapable (old) kernel will recognize that it does not understand the new feature, and refuse to mount the filesystem.

== Q: Does it run on platforms other than i386? ==

XFS runs on all of the platforms that Linux supports. It is more tested on the more common platforms, especially the i386 family. Its also well tested on the IA64 platform since thats the platform SGI Linux products use.

== Q: Quota: Do quotas work on XFS? ==

Yes.

To use quotas with XFS, you need to enable XFS quota support when you configure your kernel. You also need to specify quota support when mounting. You can get the Linux quota utilities at their sourceforge website [http://sourceforge.net/projects/linuxquota/ http://sourceforge.net/projects/linuxquota/] or use '''xfs_quota(8)'''.

== Q: Quota: What's project quota? ==

The project quota is a quota mechanism in XFS can be used to implement a form of directory tree quota, where a specified directory and all of the files and subdirectories below it (i.e. a tree) can be restricted to using a subset of the available space in the filesystem.

== Q: Quota: Can group quota and project quota be used at the same time? ==

No, project quota cannot be used with group quota at the same time. On the other hand user quota and project quota can be used simultaneously.

== Q: Quota: Is umounting prjquota (project quota) enabled fs and mounting it again with grpquota (group quota) removing prjquota limits previously set from fs (and vice versa) ? ==

To be answered.

== Q: Are there any dump/restore tools for XFS? ==

'''xfsdump(8)''' and '''xfsrestore(8)''' are fully supported. The tape format is the same as on IRIX, so tapes are interchangeable between operating systems.

== Q: Does LILO work with XFS? ==

This depends on where you install LILO.

Yes, for MBR (Master Boot Record) installations.

No, for root partition installations because the XFS superblock is written at block zero, where LILO would be installed. This is to maintain compatibility with the IRIX on-disk format, and will not be changed.

== Q: Does GRUB work with XFS? ==

There is native XFS filesystem support for GRUB starting with version 0.91 and onward. Unfortunately, GRUB used to make incorrect assumptions about being able to read a block device image while a filesystem is mounted and actively being written to, which could cause intermittent problems when using XFS. This has reportedly since been fixed, and the 0.97 version (at least) of GRUB is apparently stable.

== Q: Can XFS be used for a root filesystem? ==

Yes, with one caveat: Linux does not support an external XFS journal for the root filesystem via the "rootflags=" kernel parameter. To use an external journal for the root filesystem in Linux, an init ramdisk must mount the root filesystem with explicit "logdev=" specified. [http://mindplusplus.wordpress.com/2008/07/27/scratching-an-i.html More information here.]

== Q: Will I be able to use my IRIX XFS filesystems on Linux? ==

Yes. The on-disk format of XFS is the same on IRIX and Linux. Obviously, you should back-up your data before trying to move it between systems. Filesystems must be "clean" when moved (i.e. unmounted). If you plan to use IRIX filesystems on Linux keep the following points in mind: the kernel needs to have SGI partition support enabled; there is no XLV support in Linux, so you are unable to read IRIX filesystems which use the XLV volume manager; also not all blocksizes available on IRIX are available on Linux (only blocksizes less than or equal to the pagesize of the architecture: 4k for i386, ppc, ... 8k for alpha, sparc, ... is possible for now). Make sure that the directory format is version 2 on the IRIX filesystems (this is the default since IRIX 6.5.5). Linux can only read v2 directories.

== Q: Is there a way to make a XFS filesystem larger or smaller? ==

You can ''NOT'' make a XFS partition smaller online. The only way to shrink is to do a complete dump, mkfs and restore.

An XFS filesystem may be enlarged by using '''xfs_growfs(8)'''.

If using partitions, you need to have free space after this partition to do so. Remove partition, recreate it larger with the ''exact same'' starting point. Run '''xfs_growfs''' to make the partition larger. Note - editing partition tables is a dangerous pastime, so back up your filesystem before doing so.

Using XFS filesystems on top of a volume manager makes this a lot easier.

== Q: What information should I include when reporting a problem? ==

Things to include are what version of XFS you are using, if this is a CVS version of what date and version of the kernel. If you have problems with userland packages please report the version of the package you are using.

If the problem relates to a particular filesystem, the output from the '''xfs_info(8)''' command and any '''mount(8)''' options in use will also be useful to the developers.

If you experience an oops, please run it through '''ksymoops''' so that it can be interpreted.

If you have a filesystem that cannot be repaired, make sure you have xfsprogs 2.9.0 or later and run '''xfs_metadump(8)''' to capture the metadata (which obfuscates filenames and attributes to protect your privacy) and make the dump available for someone to analyse.

== Q: Mounting an XFS filesystem does not work - what is wrong? ==

If mount prints an error message something like:

mount: /dev/hda5 has wrong major or minor number

you either do not have XFS compiled into the kernel (or you forgot to load the modules) or you did not use the "-t xfs" option on mount or the "xfs" option in <tt>/etc/fstab</tt>.

If you get something like:

mount: wrong fs type, bad option, bad superblock on /dev/sda1,
or too many mounted file systems

Refer to your system log file (<tt>/var/log/messages</tt>) for a detailed diagnostic message from the kernel.

== Q: Does the filesystem have an undelete capability? ==

There is no undelete in XFS (so far).

However at least some XFS driver implementations do not wipe file information nodes completely so there are chance to recover files with specialized commercial closed source software like [http://www.ufsexplorer.com/rdr_xfs.php Raise Data Recovery for XFS].

In this kind of XFS driver implementation it does not re-use directory entries immediately so there are chance to get back recently deleted files even with their real names.

''xfs_irecover'' or ''xfsr'' may help too, [http://www.who.is.free.fr/wiki/doku.php?id=recover this site] has a few links.

This applies to most recent Linux distributions (versions?), as well as to most popular NAS boxes that use embedded linux and XFS file system.

Anyway, the best is to always keep backups.

== Q: How can I backup a XFS filesystem and ACLs? ==

You can backup a XFS filesystem with utilities like '''xfsdump(8)''' and standard '''tar(1)''' for standard files. If you want to backup ACLs you will need to use '''xfsdump''' or [http://www.bacula.org/en/dev-manual/Current_State_Bacula.html Bacula] (> version 3.1.4) or [http://rsync.samba.org/ rsync] (>= version 3.0.0) to backup ACLs and EAs. '''xfsdump''' can also be integrated with [http://www.amanda.org/ amanda(8)].

== Q: I see applications returning error 990 or "Structure needs cleaning", what is wrong? ==

The error 990 stands for [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=blob;f=fs/xfs/linux-2.6/xfs_linux.h#l145 EFSCORRUPTED] which usually means XFS has detected a filesystem metadata problem and has shut the filesystem down to prevent further damage. Also, since about June 2006, we [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commit;h=da2f4d679c8070ba5b6a920281e495917b293aa0 converted from EFSCORRUPTED/990 over to using EUCLEAN], "Structure needs cleaning."

The cause can be pretty much anything, unfortunately - filesystem, virtual memory manager, volume manager, device driver, or hardware.

There should be a detailed console message when this initially happens. The messages have important information giving hints to developers as to the earliest point that a problem was detected. It is there to protect your data.

You can use xfs_check and xfs_repair to remedy the problem (with the file system unmounted).

== Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? ==

Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1.

XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash.

Since XFS does not write data out immediately unless you tell it to with fsync, an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are looking at an inode which was flushed out, but whose data was not. Typically you'll find that the inode is not taking any space since all it has is a size but no extents allocated (try examining the file with the '''xfs_bmap(8)''' command).

== Q: What is the problem with the write cache on journaled filesystems? ==

Many drives use a write back cache in order to speed up the performance of writes. However, there are conditions such as power failure when the write cache memory is never flushed to the actual disk. Further, the drive can de-stage data from the write cache to the platters in any order that it chooses. This causes problems for XFS and journaled filesystems in general because they rely on knowing when a write has completed to the disk. They need to know that the log information has made it to disk before allowing metadata to go to disk. When the metadata makes it to disk then the transaction can effectively be deleted from the log resulting in movement of the tail of the log and thus freeing up some log space. So if the writes never make it to the physical disk, then the ordering is violated and the log and metadata can be lost, resulting in filesystem corruption.

With hard disk cache sizes of currently (Jan 2009) up to 32MB that can be a lot of valuable information. In a RAID with 8 such disks these adds to 256MB, and the chance of having filesystem metadata in the cache is so high that you have a very high chance of big data losses on a power outage.

With a single hard disk and barriers turned on (on=default), the drive write cache is flushed before and after a barrier is issued. A powerfail "only" loses data in the cache but no essential ordering is violated, and corruption will not occur.

With a RAID controller with battery backed controller cache and cache in write back mode, you should turn off barriers - they are unnecessary in this case, and if the controller honors the cache flushes, it will be harmful to performance. But then you *must* disable the individual hard disk write cache in order to ensure to keep the filesystem intact after a power failure. The method for doing this is different for each RAID controller. See the section about RAID controllers below.

== Q: How can I tell if I have the disk write cache enabled? ==

For SCSI/SATA:

* Look in dmesg(8) output for a driver line, such as:<br /> "SCSI device sda: drive cache: write back"
* <nowiki># sginfo -c /dev/sda | grep -i 'write cache' </nowiki>

For PATA/SATA (although for SATA this only works on a recent kernel with ATA command passthrough):

* <nowiki># hdparm -I /dev/sda</nowiki><br /> and look under "Enabled Supported" for "Write cache"

For RAID controllers:

* See the section about RAID controllers below

== Q: How can I address the problem with the disk write cache? ==

=== Disabling the disk write back cache. ===

For SATA/PATA(IDE): (although for SATA this only works on a recent kernel with ATA command passthrough):<br />

* <nowiki># hdparm -W0 /dev/sda</nowiki><br /> # hdparm -W0 /dev/hda
* <nowiki># blktool /dev/sda wcache off</nowiki><br /> # blktool /dev/hda wcache off

For SCSI:

* Using sginfo(8) which is a little tedious<br /> It takes 3 steps. For example:
*# <nowiki>#sginfo -c /dev/sda</nowiki><br /> which gives a list of attribute names and values
*# <nowiki>#sginfo -cX /dev/sda</nowiki><br /> which gives an array of cache values which you must match up with from step 1, e.g.<br /> 0 0 0 1 0 1 0 0 0 0 65535 0 65535 65535 1 0 0 0 3 0 0
*# <nowiki>#sginfo -cXR /dev/sda 0 0 0 1 0 0 0 0 0 0 65535 0 65535 65535 1 0 0 0 3 0 0</nowiki><br /> allows you to reset the value of the cache attributes.

For RAID controllers:

* See the section about RAID controllers below

This disabling is kept persistent for a SCSI disk. However, for a SATA/PATA disk this needs to be done after every reset as it will reset back to the default of the write cache enabled. And a reset can happen after reboot or on error recovery of the drive. This makes it rather difficult to guarantee that the write cache is maintained as disabled.<br />

=== Using an external log. ===

Some people have considered the idea of using an external log on a separate drive with the write cache disabled and the rest of the file system on another disk with the write cache enabled. However, that will '''not''' solve the problem. For example, the tail of the log is moved when we are notified that a metadata write is completed to disk and we won't be able to guarantee that if the metadata is on a drive with the write cache enabled.

In fact using an external log will disable XFS' write barrier support.

=== Write barrier support. ===

Write barrier support is enabled by default in XFS since kernel version 2.6.17. It is disabled by mounting the filesystem with "nobarrier". Barrier support will flush the write back cache at the appropriate times (such as on XFS log writes). This is generally the recommended solution, however, you should check the system logs to ensure it was successful. Barriers will be disabled and reported in the log if any of the 3 scenarios occurs:

* "Disabling barriers, not supported with external log device"
* "Disabling barriers, not supported by the underlying device"
* "Disabling barriers, trial barrier write failed"

If the filesystem is mounted with an external log device then we currently don't support flushing to the data and log devices (this may change in the future). If the driver tells the block layer that the device does not support write cache flushing with the write cache enabled then it will report that the device doesn't support it. And finally we will actually test out a barrier write on the superblock and test its error state afterwards, reporting if it fails.

== 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". But take care about the hard disk write cache, which should be off.

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

It's hard to tell because there are so many controllers. Please consult your RAID controller documentation to determine how to change these settings, but we try to give an overview here:

Real RAID controllers (not those found onboard of mainboards) normally have a battery backed cache (or an [http://en.wikipedia.org/wiki/Electric_double-layer_capacitor ultracapacitor] + flash memory "[http://www.tweaktown.com/articles/2800/adaptec_zero_maintenance_cache_protection_explained/ zero maintenance cache]") which is used for buffering writes to improve speed. Even if it's battery backed, the individual hard disk write caches need to be turned off, as they are not protected from a powerfail and will just lose all contents in that case.

* onboard RAID controllers: there are so many different types it's hard to tell. Generally, those controllers have no cache, but let the hard disk write cache on. That can lead to the bad situation that after a powerfail with RAID-1 when only parts of the disk cache have been written, the controller doesn't even see that the disks are out of sync, as the disks can resort cached blocks and might have saved the superblock info, but then lost different data contents. So, turn off disk write caches before using the RAID function.

* 3ware: /cX/uX set cache=off, see http://www.3ware.com/support/UserDocs/CLIGuide-9.5.1.1.pdf , page 86

* Adaptec: allows setting individual drives cache
arcconf setcache <disk> wb|wt
wb=write back, which means write cache on, wt=write through, which means write cache off. So "wt" should be chosen.

* Areca: In archttp under "System Controls" -> "System Configuration" there's the option "Disk Write Cache Mode" (defaults "Auto")

"Off": disk write cache is turned off

"On": disk write cache is enabled, this is not safe for your data but fast

"Auto": If you use a BBM (battery backup module, which you really should use if you care about your data), the controller automatically turns disk writes off, to protect your data. In case no BBM is attached, the controller switches to "On", because neither controller cache nor disk cache is safe so you don't seem to care about your data and just want high speed (which you get then).

That's a very sensible default so you can let it "Auto" or enforce "Off" to be sure.

* LSI MegaRAID: allows setting individual disks cache:
MegaCli -AdpCacheFlush -aN|-a0,1,2|-aALL # flushes the controller cache
MegaCli -LDGetProp -Cache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # shows the controller cache settings
MegaCli -LDGetProp -DskCache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # shows the disk cache settings (for all phys. disks in logical disk)
MegaCli -LDSetProp -EnDskCache|DisDskCache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # set disk cache setting

* Xyratex: from the docs: "Write cache includes the disk drive cache and controller cache.". So that means you can only set the drive caches and the unit caches together. To protect your data, turn it off, but write performance will suffer badly as also the controller write cache is disabled.

== Q: Which settings are best with virtualization like VMware, XEN, qemu? ==

The biggest problem is that those products seem to also virtualize disk
writes in a way that even barriers don't work any more, which means even
a fsync is not reliable. Tests confirm that unplugging the power from
such a system even with RAID controller with battery backed cache and
hard disk cache turned off (which is safe on a normal host) you can
destroy a database within the virtual machine (client, domU whatever you
call it).

In qemu you can specify cache=off on the line specifying the virtual
disk. For others information is missing.

== Q: What is the issue with directory corruption in Linux 2.6.17? ==

In the Linux kernel 2.6.17 release a subtle bug was accidentally introduced into the XFS directory code by some "sparse" endian annotations. This bug was sufficiently uncommon (it only affects a certain type of format change, in Node or B-Tree format directories, and only in certain situations) that it was not detected during our regular regression testing, but it has been observed in the wild by a number of people now.

''Update: the fix is included in 2.6.17.7 and later kernels.''

To add insult to injury, '''xfs_repair(8)''' is currently not correcting these directories on detection of this corrupt state either. This '''xfs_repair''' issue is actively being worked on, and a fixed version will be available shortly.

''Update: a fixed '''xfs_repair''' is now available; version 2.8.10 or later of the xfsprogs package contains the fixed version.''

No other kernel versions are affected. However, using a corrupt filesystem on other kernels can still result in the filesystem being shutdown if the problem has not been rectified (on disk), making it seem like other kernels are affected.

The '''xfs_check''' tool, or '''xfs_repair -n''', should be able to detect any directory corruption.

Until a fixed '''xfs_repair''' binary is available, one can make use of the '''xfs_db(8)''' command to mark the problem directory for removal (see the example below). A subsequent '''xfs_repair''' invocation will remove the directory and move all contents into "lost+found", named by inode number (see second example on how to map inode number to directory entry name, which needs to be done _before_ removing the directory itself). The inode number of the corrupt directory is included in the shutdown report issued by the kernel on detection of directory corruption. Using that inode number, this is how one would ensure it is removed:

<nowiki>
# xfs_db -x /dev/sdXXX
xfs_db> inode NNN
xfs_db> print
core.magic = 0x494e
core.mode = 040755
core.version = 2
core.format = 3 (btree)
...
xfs_db> write core.mode 0
xfs_db> quit
</nowiki>

A subsequent '''xfs_repair''' will clear the directory, and add new entries (named by inode number) in lost+found.

The easiest way to map inode numbers to full paths is via '''xfs_ncheck(8)'''<nowiki>: </nowiki>

<nowiki>
# xfs_ncheck -i 14101 -i 14102 /dev/sdXXX
14101 full/path/mumble_fratz_foo_bar_1495
14102 full/path/mumble_fratz_foo_bar_1494
</nowiki>

Should this not work, we can manually map inode numbers in B-Tree format directory by taking the following steps:

<nowiki>
# xfs_db -x /dev/sdXXX
xfs_db> inode NNN
xfs_db> print
core.magic = 0x494e
...
next_unlinked = null
u.bmbt.level = 1
u.bmbt.numrecs = 1
u.bmbt.keys[1] = [startoff] 1:[0]
u.bmbt.ptrs[1] = 1:3628
xfs_db> fsblock 3628
xfs_db> type bmapbtd
xfs_db> print
magic = 0x424d4150
level = 0
numrecs = 19
leftsib = null
rightsib = null
recs[1-19] = [startoff,startblock,blockcount,extentflag]
1:[0,3088,4,0] 2:[4,3128,8,0] 3:[12,3308,4,0] 4:[16,3360,4,0]
5:[20,3496,8,0] 6:[28,3552,8,0] 7:[36,3624,4,0] 8:[40,3633,4,0]
9:[44,3688,8,0] 10:[52,3744,4,0] 11:[56,3784,8,0]
12:[64,3840,8,0] 13:[72,3896,4,0] 14:[33554432,3092,4,0]
15:[33554436,3488,8,0] 16:[33554444,3629,4,0]
17:[33554448,3748,4,0] 18:[33554452,3900,4,0]
19:[67108864,3364,4,0]
</nowiki>

At this point we are looking at the extents that hold all of the directory information. There are three types of extent here, we have the data blocks (extents 1 through 13 above), then the leaf blocks (extents 14 through 18), then the freelist blocks (extent 19 above). The jumps in the first field (start offset) indicate our progression through each of the three types. For recovering file names, we are only interested in the data blocks, so we can now feed those offset numbers into the '''xfs_db''' dblock command. So, for the fifth extent - 5:[20,3496,8,0] - listed above:

...
xfs_db> dblock 20
xfs_db> print
dhdr.magic = 0x58443244
dhdr.bestfree[0].offset = 0
dhdr.bestfree[0].length = 0
dhdr.bestfree[1].offset = 0
dhdr.bestfree[1].length = 0
dhdr.bestfree[2].offset = 0
dhdr.bestfree[2].length = 0
du[0].inumber = 13937
du[0].namelen = 25
du[0].name = "mumble_fratz_foo_bar_1595"
du[0].tag = 0x10
du[1].inumber = 13938
du[1].namelen = 25
du[1].name = "mumble_fratz_foo_bar_1594"
du[1].tag = 0x38
...

So, here we can see that inode number 13938 matches up with name "mumble_fratz_foo_bar_1594". Iterate through all the extents, and extract all the name-to-inode-number mappings you can, as these will be useful when looking at "lost+found" (once '''xfs_repair''' has removed the corrupt directory).

== Q: Why does my > 2TB XFS partition disappear when I reboot ? ==

Strictly speaking this is not an XFS problem.

To support > 2TB partitions you need two things: a kernel that supports large block devices (<tt>CONFIG_LBD=y</tt>) and a partition table format that can hold large partitions. The default DOS partition tables don't. The best partition format for
> 2TB partitions is the EFI GPT format (<tt>CONFIG_EFI_PARTITION=y</tt>).

Without CONFIG_LBD=y you can't even create the filesystem, but without <tt>CONFIG_EFI_PARTITION=y</tt> it works fine until you reboot at which point the partition will disappear. Note that you need to enable the <tt>CONFIG_PARTITION_ADVANCED</tt> option before you can set <tt>CONFIG_EFI_PARTITION=y</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. To fix this, [http://oss.sgi.com/pipermail/xfs/2009-January/039835.html Dave Chinner advised]:

The only way to fix this is to move data around to free up space
below 1TB. Find your oldest data (i.e. that was around before even
the first grow) and move it off the filesystem (move, not copy).
Then if you copy it back on, the data blocks will end up above 1TB
and that should leave you with plenty of space for inodes below 1TB.

A complete dump and restore will also fix the problem ;)

Also, you can add 'inode64' to your mount options to allow inodes to live above 1TB.

example:[https://www.centos.org/modules/newbb/viewtopic.php?topic_id=30703&forum=38 | No space left on device on xfs filesystem with 7.7TB free]

== Q: Is using noatime or/and nodiratime at mount time giving any performance benefits in xfs (or not using them performance decrease)? ==

The default atime behaviour is relatime, which has almost no overhead compared to noatime but still maintains sane atime values. All Linux filesystems use this as the default now (since around 2.6.30), but XFS has used relatime-like behaviour since 2006, so no-one should really need to ever use noatime on XFS for performance reasons.

Also, noatime implies nodiratime, so there is never a need to specify nodiratime when noatime is also specified.

== Q: How to get around a bad inode repair is unable to clean up ==

The trick is go in with xfs_db and mark the inode as a deleted, which will cause repair to clean it up and finish the remove process.

xfs_db -x -c 'inode XXX' -c 'write core.nextents 0' -c 'write core.size 0' /dev/hdXX

== Q: How to calculate the correct sunit,swidth values for optimal performance ==

XFS allows to optimize for a given RAID stripe unit (stripe size) and stripe width (number of data disks) via mount options.

These options can be sometimes autodetected (for example with md raid and recent enough kernel (>= 2.6.32) and xfsprogs (>= 3.1.1) built with libblkid support) but manual calculation is needed for most of hardware raids.

The calculation of these values is quite simple:

su = <RAID controllers stripe size in BYTES (or KiBytes when used with k)>
sw = <# of data disks (don't count parity disks)>

So if your RAID controller has a stripe size of 64KB, and you have a RAID-6 with 8 disks, use

su = 64k
sw = 6 (RAID-6 of 8 disks has 6 data disks)

A RAID stripe size of 256KB with a RAID-10 over 16 disks should use

su = 256k
sw = 8 (RAID-10 of 16 disks has 8 data disks)

Alternatively, you can use "sunit" instead of "su" and "swidth" instead of "sw" but then sunit/swidth values need to be specified in "number of 512B sectors"!

Note that <tt>xfs_info</tt> and <tt>mkfs.xfs</tt> interpret sunit and swidth as being specified in units of 512B sectors; that's unfortunately not the unit they're reported in, however.
<tt>xfs_info</tt> and <tt>mkfs.xfs</tt> report them in multiples of your basic block size (bsize) and not in 512B sectors.

Assume for example: swidth 1024 (specified at mkfs.xfs command line; so 1024 of 512B sectors) and block size of 4096 (bsize reported by mkfs.xfs at output). You should see swidth 128 (reported by mkfs.xfs at output). 128 * 4096 == 1024 * 512.

When creating XFS filesystem on top of LVM on top of hardware raid please use sunit/swith values as when creating XFS filesystem directly on top of hardware raid.

== Q: Why doesn't NFS-exporting subdirectories of inode64-mounted filesystem work? ==

The default <tt>fsid</tt> type encodes only 32-bit of the inode number for subdirectory exports. However, exporting the root of the filesystem works, or using one of the non-default <tt>fsid</tt> types (<tt>fsid=uuid</tt> in <tt>/etc/exports</tt> with recent <tt>nfs-utils</tt>) should work as well. (Thanks, Christoph!)

== Q: What is the inode64 mount option for? ==

By default, with 32bit inodes, XFS places inodes only in the first 1TB of a disk. If you have a disk with 100TB, all inodes will be stuck in the first TB. This can lead to strange things like "disk full" when you still have plenty space free, but there's no more place in the first TB to create a new inode. Also, performance sucks.

To come around this, use the inode64 mount options for filesystems >1TB. Inodes will then be placed in the location where their data is, minimizing disk seeks.

Beware that some old programs might have problems reading 64bit inodes, especially over NFS. Your editor used inode64 for over a year with recent (openSUSE 11.1 and higher) distributions using NFS and Samba without any corruptions, so that might be a recent enough distro.

== Q: Can I just try the inode64 option to see if it helps me? ==

Starting from kernel 2.6.35, you can try and then switch back. Older kernels have a bug leading to strange problems if you mount without inode64 again. For example, you can't access files & dirs that have been created with an inode >32bit anymore.

== Q: Performance: mkfs.xfs -n size=64k option ==

Asking the implications of that mkfs option on the XFS mailing list, Dave Chinner explained it this way:

Inodes are not stored in the directory structure, only the directory entry name and the inode number. Hence the amount of space used by a
directory entry is determined by the length of the name.

There is extra overhead to allocate large directory blocks (16 pages instead of one, to begin with, then there's the vmap overhead, etc), so for small directories smaller block sizes are faster for create and unlink operations.

For empty directories, operations on 4k block sized directories consume roughly 50% less CPU that 64k block size directories. The 4k block size directories consume less CPU out to roughly 1.5 million entries where the two are roughly equal. At directory sizes of 10 million entries, 64k directory block operations are consuming about 15% of the CPU that 4k directory block operations consume.

In terms of lookups, the 64k block directory will take less IO but consume more CPU for a given lookup. Hence it depends on your IO latency and whether directory readahead can hide that latency as to which will be faster. e.g. For SSDs, CPU usage might be the limiting factor, not the IO. Right now I don't have any numbers on what the difference might be - I'm getting 1 billion inode population issues worked out first before I start on measuring cold cache lookup times on 1 billion files....

== Q: I want to tune my XFS filesystems for <something> ==

The standard answer you will get to this question is this: use the defaults.

There are few workloads where using non-default mkfs.xfs or mount options make much sense. In general, the default values already used are optimised for best performance in the first place. mkfs.xfs will detect the difference between single disk and MD/DM RAID setups and change the default values it uses to configure the filesystem appropriately.

There are a lot of "XFS tuning guides" that Google will find for you - most are old, out of date and full of misleading or just plain incorrect information. Don't expect that tuning your filesystem for optimal bonnie++ numbers will mean your workload will go faster. You should only consider changing the defaults if either: a) you know from experience that your workload causes XFS a specific problem that can be worked around via a configuration change, or b) your workload is demonstrating bad performance when using the default configurations. In this case, you need to understand why your application is causing bad performance before you start tweaking XFS configurations.

In most cases, the only thing you need to to consider for <tt>mkfs.xfs</tt> is specifying the stripe unit and width for hardware RAID devices. For mount options, the only thing that will change metadata performance considerably are the <tt>logbsize</tt> and <tt>delaylog</tt> mount options. Increasing <tt>logbsize</tt> reduces the number of journal IOs for a given workload, and <tt>delaylog</tt> will reduce them even further. The trade off for this increase in metadata performance is that more operations may be "missing" after recovery if the system crashes while actively making modifications.

== Q: Which factors influence the memory usage of xfs_repair? ==

This is best explained with an example. The example filesystem is 16Tb, but basically empty (look at icount).

# xfs_repair -n -vv -m 1 /dev/vda
Phase 1 - find and verify superblock...
- max_mem = 1024, icount = 64, imem = 0, dblock = 4294967296, dmem = 2097152
Required memory for repair is greater that the maximum specified
with the -m option. Please increase it to at least 2096.
#

xfs_repair is saying it needs at least 2096MB of RAM to repair the filesystem,
of which 2,097,152KB is needed for tracking free space.
(The -m 1 argument was telling xfs_repair to use ony 1 MB of memory.)

Now if we add some inodes (50 million) to the filesystem (look at icount again), and the result is:

# xfs_repair -vv -m 1 /dev/vda
Phase 1 - find and verify superblock...
- max_mem = 1024, icount = 50401792, imem = 196882, dblock = 4294967296, dmem = 2097152
Required memory for repair is greater that the maximum specified
with the -m option. Please increase it to at least 2289.

That is now needs at least another 200MB of RAM to run.

The numbers reported by xfs_repair are the absolute minimum required and approximate at that;
more RAM than this may be required to complete successfully.
Also, if you only give xfs_repair the minimum required RAM, it will be slow;
for best repair performance, the more RAM you can give it the better.

== Q: Why some files of my filesystem shows as "?????????? ? ? ? ? ? filename" ? ==

If ls -l shows you a listing as

# ?????????? ? ? ? ? ? file1
?????????? ? ? ? ? ? file2
?????????? ? ? ? ? ? file3
?????????? ? ? ? ? ? file4

and errors like:
# ls /pathtodir/
ls: cannot access /pathtodir/file1: Invalid argument
ls: cannot access /pathtodir/file2: Invalid argument
ls: cannot access /pathtodir/file3: Invalid argument
ls: cannot access /pathtodir/file4: Invalid argument

or even:
# failed to stat /pathtodir/file1

It is very probable your filesystem must be mounted with inode64
# mount -oremount,inode64 /dev/diskpart /mnt/xfs

should make it work ok again.
If it works, add the option to fstab.

Main Page

2012-01-27T00:09:25Z

Ckujau: video presentation moved to XFS Papers and Documentation

__NOTOC__
{| width="100%"
|-
|style="vertical-align:top" | 
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#E2EAFF; align:right;">

== Information about XFS ==

* [[XFS FAQ]]
* [[XFS Status Updates]]
* [[XFS Papers and Documentation]]
* [[Linux Distributions shipping XFS]]
* [[XFS Rpm for RedHat|XFS RPMs for RedHat]]
* [[XFS Companies]]
* [http://oss.sgi.com/projects/xfs SGI XFS website]
* [http://en.wikipedia.org/wiki/XFS Wikipedia XFS page]

== Professional XFS Consulting Services ==

[[Consulting Resources]]
</div>

| width="50%" style="vertical-align:top" |


<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#F8F8FF; align:right;">
== XFS Developer Resources ==

* [[XFS email list and archives]]
* [http://oss.sgi.com/bugzilla/buglist.cgi?product=XFS&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Bugzilla @ oss.sgi.com]
* [http://bugzilla.kernel.org/buglist.cgi?product=File+System&component=XFS&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Bugzilla @ kernel.org]
* [[Getting the latest source code]]
* [[Unfinished work]]
* [[Shrinking Support]]
* [[Ideas for XFS]]
</div>


<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#F2F2F2; align:right;">

== Feature Highlights ==

* [[FITRIM/discard]] - discard (or "trim") blocks which are not in use by the filesystem
</div>

{{#meta: | u+4/+rib+YG96TifD0SN88xS84YSDm2cl61IU7ZIk9g= | verify-v1 }}
|}

XFS Papers and Documentation

2012-01-27T00:08:56Z

Ckujau: XFS: Recent and Future Adventures in Filesystem Scalability - Dave Chinner

=== Primary XFS Documentation ===

The XFS documentation started by SGI has been converted to docbook/[https://fedorahosted.org/publican/ Publican] format. The material is suitable for experienced users as well as developers and support staff. The XML source is available in a [http://git.kernel.org/?p=fs/xfs/xfsdocs-xml-dev.git;a=summary git repository] and builds of the documentation are available here:

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.html XFS User Guide]

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html XFS File System Structure]
** [http://sites.google.com/site/kandamotohiro/xfs Japanese translation] is also available.

* [http://xfs.org/docs/xfsdocs-xml-dev/XFS_Labs/tmp/en-US/html/index.html XFS Training Labs]

* (Original versions of this material are still available at [http://oss.sgi.com/projects/xfs/training/index.html XFS Overview and Internals (html)] and [http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf XFS Filesystem Structure (pdf)]

The format of <tt>/proc/fs/xfs/stat</tt> also has been documented:
* [[Runtime_Stats|Runtime_Stats]]

=== Papers, Presentations, Etc ===

* [http://www.youtube.com/watch?v=FegjLbCnoBw Video "Recent and Future Adventures in Filesystem Scalability" - Dave Chinner ]

The October 2009 issue of the USENIX ;login: magazine published an article about XFS targeted at system administrators:

* ''XFS: The big storage file system for Linux'' [[http://oss.sgi.com/projects/xfs/papers/hellwig.pdf pdf]]

At the Ottawa Linux Symposium (July 2006), Dave Chinner presented a paper on filesystem scalability in Linux 2.6 kernels:

* ''High Bandwidth Filesystems on Large Systems'' (July 2006) [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf paper]] [[http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-presentation.pdf presentation]]

At linux.conf.au 2008 Dave Chinner gave a presentation about xfs_repair that he co-authored with Barry Naujok:

* Fixing XFS Filesystems Faster [[http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf pdf]]

In July 2006, SGI storage marketing updated the XFS datasheet:

* ''Open Source XFS for Linux'' [[http://oss.sgi.com/projects/xfs/datasheet.pdf pdf]]

At UKUUG 2003, Christoph Hellwig presented a talk on XFS:

* ''XFS for Linux'' (July 2003) [[http://oss.sgi.com/projects/xfs/papers/ukuug2003.pdf pdf]] [[http://verein.lst.de/~hch/talks/ukuug2003/ html]]

Originally published in Proceedings of the FREENIX Track: 2002 Usenix Annual Technical Conference:

* ''Filesystem Performance and Scalability in Linux 2.4.17'' (June 2002) [[http://oss.sgi.com/projects/xfs/papers/filesystem-perf-tm.pdf pdf]]

At the Ottawa Linux Symposium, an updated presentation on porting XFSÂ to Linux was given:

* ''Porting XFS to Linux'' (July 2000) [[http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm html]]

At the Atlanta Linux Showcase, SGI presented the following paper on the port of XFS to Linux:

* ''Porting the SGI XFS File System to Linux'' (October 1999) [[http://oss.sgi.com/projects/xfs/papers/als/als.ps ps]] [[http://oss.sgi.com/projects/xfs/papers/als/als.pdf pdf]]

At the 6th Linux Kongress & the Linux Storage Management Workshop (LSMW) in Germany in September, 1999, SGI had a few presentations including the following:

* ''SGI's port of XFS to Linux'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/linux_kongress/index.htm html]]
* ''Overview of DMF'' (September 1999) [[http://oss.sgi.com/projects/xfs/papers/DMF-over/index.htm html]]

At the LinuxWorld Conference & Expo in August 1999, SGI published:

* ''An Open Source XFS data sheet'' (August 1999) [[http://oss.sgi.com/projects/xfs/papers/xfs_GPL.pdf pdf]]

From the 1996 USENIX conference:

* ''An XFS white paper'' [[http://oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html html]]

=== Other historical articles, press-releases, etc ===

* IBM's ''Advanced Filesystem Implementor's Guide'' has a chapter ''Introducing XFS'' [[http://www-106.ibm.com/developerworks/library/l-fs9.html html]]

* An editorial titled ''Tired of fscking? Try a journaling filesystem!'', Freshmeat (February 2001) [[http://freshmeat.net/articles/view/212/ html]]

* ''Who give a fsck about filesystems'' provides an overview of the Linux 2.4 filesystems [[http://www.linuxuser.co.uk/articles/issue6/lu6-All_you_need_to_know_about-Filesystems.pdf html]]

* ''Journal File Systems'' in issue 55 of ''Linux Gazette'' provides a comparison of journaled filesystems.

* The original XFS beta release announcement was published in ''Linux Today'' (September 2000) [[http://linuxtoday.com/news_story.php3?ltsn=2000-09-26-017-04-OS-SW html]]

* ''XFS: It's worth the wait'' was published on ''EarthWeb'' (July 2000) [[http://networking.earthweb.com/netos/oslin/article/0,,12284_623661,00.html html]]

* An ''IRIX-XFS data sheet'' (July 1999) [[http://oss.sgi.com/projects/xfs/papers/IRIX_xfs_data_sheet.pdf pdf]]

* The ''Getting Started with XFS'' book (1994) [[http://oss.sgi.com/projects/xfs/papers/getting_started_with_xfs.pdf pdf]]

* Original ''XFS design documents'' (1993) ([http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_ps/ ps], [http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/ pdf])

Status/2008-August

2012-01-15T18:21:43Z

Ckujau: double redirect fixed (sorry)

#REDIRECT [[XFS_Status_Updates#XFS_status_update_for_August_2008]]

XFS Status August 2008

2012-01-15T18:21:39Z

Ckujau: double redirect fixed (sorry)

#REDIRECT [[XFS_Status_Updates#XFS_status_update_for_August_2008]]

XFS status update for August 2008

2012-01-15T18:21:36Z

Ckujau: double redirect fixed (sorry)

#REDIRECT [[XFS_Status_Updates#XFS_status_update_for_August_2008]]

XFS status update for August 2008

2012-01-15T18:18:03Z

Ckujau: -> Current_events#XFS_status_update_for_August_2008

#REDIRECT [[Current_events#XFS_status_update_for_August_2008]]

XFS Status August 2008

2012-01-15T18:17:27Z

Ckujau: -> Current_events#XFS_status_update_for_August_2008

#REDIRECT [[Current_events#XFS_status_update_for_August_2008]]

XFS FAQ

2011-12-27T21:48:07Z

Ckujau: Undo revision 2383 by ColleenGrimes (Talk)

Info from: [http://oss.sgi.com/projects/xfs/faq.html main XFS faq at SGI]

Many thanks to earlier maintainers of this document - Thomas Graichen and Seth Mos.

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

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''.

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

Andreas Gruenbacher maintains the Extended Attribute and POSIX ACL documentation for Linux at http://acl.bestbits.at/

The '''acl(5)''' manual page is also quite extensive.

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

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.

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

Linux native filesystem (83).

== Q: What mount options does XFS have? ==

There are a number of mount options influencing XFS filesystems - refer to the '''mount(8)''' manual page or the documentation in the kernel source tree itself ([http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/xfs.txt;hb=HEAD Documentation/filesystems/xfs.txt])

== Q: Is there any relation between the XFS utilities and the kernel version? ==

No, there is no relation. Newer utilities tend to mainly have fixes and checks the previous versions might not have. New features are also added in a backward compatible way - if they are enabled via mkfs, an incapable (old) kernel will recognize that it does not understand the new feature, and refuse to mount the filesystem.

== Q: Does it run on platforms other than i386? ==

XFS runs on all of the platforms that Linux supports. It is more tested on the more common platforms, especially the i386 family. Its also well tested on the IA64 platform since thats the platform SGI Linux products use.

== Q: Quota: Do quotas work on XFS? ==

Yes.

To use quotas with XFS, you need to enable XFS quota support when you configure your kernel. You also need to specify quota support when mounting. You can get the Linux quota utilities at their sourceforge website [http://sourceforge.net/projects/linuxquota/ http://sourceforge.net/projects/linuxquota/] or use '''xfs_quota(8)'''.

== Q: Quota: What's project quota? ==

The project quota is a quota mechanism in XFS can be used to implement a form of directory tree quota, where a specified directory and all of the files and subdirectories below it (i.e. a tree) can be restricted to using a subset of the available space in the filesystem.

== Q: Quota: Can group quota and project quota be used at the same time? ==

No, project quota cannot be used with group quota at the same time. On the other hand user quota and project quota can be used simultaneously.

== Q: Quota: Is umounting prjquota (project quota) enabled fs and mounting it again with grpquota (group quota) removing prjquota limits previously set from fs (and vice versa) ? ==

To be answered.

== Q: Are there any dump/restore tools for XFS? ==

'''xfsdump(8)''' and '''xfsrestore(8)''' are fully supported. The tape format is the same as on IRIX, so tapes are interchangeable between operating systems.

== Q: Does LILO work with XFS? ==

This depends on where you install LILO.

Yes, for MBR (Master Boot Record) installations.

No, for root partition installations because the XFS superblock is written at block zero, where LILO would be installed. This is to maintain compatibility with the IRIX on-disk format, and will not be changed.

== Q: Does GRUB work with XFS? ==

There is native XFS filesystem support for GRUB starting with version 0.91 and onward. Unfortunately, GRUB used to make incorrect assumptions about being able to read a block device image while a filesystem is mounted and actively being written to, which could cause intermittent problems when using XFS. This has reportedly since been fixed, and the 0.97 version (at least) of GRUB is apparently stable.

== Q: Can XFS be used for a root filesystem? ==

Yes, with one caveat: Linux does not support an external XFS journal for the root filesystem via the "rootflags=" kernel parameter. To use an external journal for the root filesystem in Linux, an init ramdisk must mount the root filesystem with explicit "logdev=" specified. [http://mindplusplus.wordpress.com/2008/07/27/scratching-an-i.html More information here.]

== Q: Will I be able to use my IRIX XFS filesystems on Linux? ==

Yes. The on-disk format of XFS is the same on IRIX and Linux. Obviously, you should back-up your data before trying to move it between systems. Filesystems must be "clean" when moved (i.e. unmounted). If you plan to use IRIX filesystems on Linux keep the following points in mind: the kernel needs to have SGI partition support enabled; there is no XLV support in Linux, so you are unable to read IRIX filesystems which use the XLV volume manager; also not all blocksizes available on IRIX are available on Linux (only blocksizes less than or equal to the pagesize of the architecture: 4k for i386, ppc, ... 8k for alpha, sparc, ... is possible for now). Make sure that the directory format is version 2 on the IRIX filesystems (this is the default since IRIX 6.5.5). Linux can only read v2 directories.

== Q: Is there a way to make a XFS filesystem larger or smaller? ==

You can ''NOT'' make a XFS partition smaller online. The only way to shrink is to do a complete dump, mkfs and restore.

An XFS filesystem may be enlarged by using '''xfs_growfs(8)'''.

If using partitions, you need to have free space after this partition to do so. Remove partition, recreate it larger with the ''exact same'' starting point. Run '''xfs_growfs''' to make the partition larger. Note - editing partition tables is a dangerous pastime, so back up your filesystem before doing so.

Using XFS filesystems on top of a volume manager makes this a lot easier.

== Q: What information should I include when reporting a problem? ==

Things to include are what version of XFS you are using, if this is a CVS version of what date and version of the kernel. If you have problems with userland packages please report the version of the package you are using.

If the problem relates to a particular filesystem, the output from the '''xfs_info(8)''' command and any '''mount(8)''' options in use will also be useful to the developers.

If you experience an oops, please run it through '''ksymoops''' so that it can be interpreted.

If you have a filesystem that cannot be repaired, make sure you have xfsprogs 2.9.0 or later and run '''xfs_metadump(8)''' to capture the metadata (which obfuscates filenames and attributes to protect your privacy) and make the dump available for someone to analyse.

== Q: Mounting an XFS filesystem does not work - what is wrong? ==

If mount prints an error message something like:

mount: /dev/hda5 has wrong major or minor number

you either do not have XFS compiled into the kernel (or you forgot to load the modules) or you did not use the "-t xfs" option on mount or the "xfs" option in <tt>/etc/fstab</tt>.

If you get something like:

mount: wrong fs type, bad option, bad superblock on /dev/sda1,
or too many mounted file systems

Refer to your system log file (<tt>/var/log/messages</tt>) for a detailed diagnostic message from the kernel.

== Q: Does the filesystem have an undelete capability? ==

There is no [[undelete]] in XFS (so far).

However at least some XFS driver implementations do not wipe file information nodes completely so there are chance to recover files with specialized commercial closed source software like [http://www.ufsexplorer.com/rdr_xfs.php Raise Data Recovery for XFS].

In this kind of XFS driver implementation it does not re-use directory entries immediately so there are chance to get back
recently deleted files even with their real names.

[[xfs_irecover]] or [[xfsr]] may help too ( http://rzr.online.fr/q/recover provide a few links )

This applies to most recent Linux distributions (versions?), as well as to most popular NAS boxes that use embedded linux and XFS file system.

Anyway, the best is to always keep backups.

== Q: How can I backup a XFS filesystem and ACLs? ==

You can backup a XFS filesystem with utilities like '''xfsdump(8)''' and standard '''tar(1)''' for standard files. If you want to backup ACLs you will need to use '''xfsdump''' or [http://www.bacula.org/en/dev-manual/Current_State_Bacula.html Bacula] (> version 3.1.4) or [http://rsync.samba.org/ rsync] (>= version 3.0.0) to backup ACLs and EAs. '''xfsdump''' can also be integrated with [http://www.amanda.org/ amanda(8)].

== Q: I see applications returning error 990 or "Structure needs cleaning", what is wrong? ==

The error 990 stands for [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=blob;f=fs/xfs/linux-2.6/xfs_linux.h#l145 EFSCORRUPTED] which usually means XFS has detected a filesystem metadata problem and has shut the filesystem down to prevent further damage. Also, since about June 2006, we [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commit;h=da2f4d679c8070ba5b6a920281e495917b293aa0 converted from EFSCORRUPTED/990 over to using EUCLEAN], "Structure needs cleaning."

The cause can be pretty much anything, unfortunately - filesystem, virtual memory manager, volume manager, device driver, or hardware.

There should be a detailed console message when this initially happens. The messages have important information giving hints to developers as to the earliest point that a problem was detected. It is there to protect your data.

You can use xfs_check and xfs_repair to remedy the problem (with the file system unmounted).

== Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? ==

Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1.

XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash.

Since XFS does not write data out immediately unless you tell it to with fsync, an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are looking at an inode which was flushed out, but whose data was not. Typically you'll find that the inode is not taking any space since all it has is a size but no extents allocated (try examining the file with the '''xfs_bmap(8)''' command).

== Q: What is the problem with the write cache on journaled filesystems? ==

Many drives use a write back cache in order to speed up the performance of writes. However, there are conditions such as power failure when the write cache memory is never flushed to the actual disk. Further, the drive can de-stage data from the write cache to the platters in any order that it chooses. This causes problems for XFS and journaled filesystems in general because they rely on knowing when a write has completed to the disk. They need to know that the log information has made it to disk before allowing metadata to go to disk. When the metadata makes it to disk then the transaction can effectively be deleted from the log resulting in movement of the tail of the log and thus freeing up some log space. So if the writes never make it to the physical disk, then the ordering is violated and the log and metadata can be lost, resulting in filesystem corruption.

With hard disk cache sizes of currently (Jan 2009) up to 32MB that can be a lot of valuable information. In a RAID with 8 such disks these adds to 256MB, and the chance of having filesystem metadata in the cache is so high that you have a very high chance of big data losses on a power outage.

With a single hard disk and barriers turned on (on=default), the drive write cache is flushed before and after a barrier is issued. A powerfail "only" loses data in the cache but no essential ordering is violated, and corruption will not occur.

With a RAID controller with battery backed controller cache and cache in write back mode, you should turn off barriers - they are unnecessary in this case, and if the controller honors the cache flushes, it will be harmful to performance. But then you *must* disable the individual hard disk write cache in order to ensure to keep the filesystem intact after a power failure. The method for doing this is different for each RAID controller. See the section about RAID controllers below.

== Q: How can I tell if I have the disk write cache enabled? ==

For SCSI/SATA:

* Look in dmesg(8) output for a driver line, such as:<br /> "SCSI device sda: drive cache: write back"
* <nowiki># sginfo -c /dev/sda | grep -i 'write cache' </nowiki>

For PATA/SATA (although for SATA this only works on a recent kernel with ATA command passthrough):

* <nowiki># hdparm -I /dev/sda</nowiki><br /> and look under "Enabled Supported" for "Write cache"

For RAID controllers:

* See the section about RAID controllers below

== Q: How can I address the problem with the disk write cache? ==

=== Disabling the disk write back cache. ===

For SATA/PATA(IDE): (although for SATA this only works on a recent kernel with ATA command passthrough):<br />

* <nowiki># hdparm -W0 /dev/sda</nowiki><br /> # hdparm -W0 /dev/hda
* <nowiki># blktool /dev/sda wcache off</nowiki><br /> # blktool /dev/hda wcache off

For SCSI:

* Using sginfo(8) which is a little tedious<br /> It takes 3 steps. For example:
*# <nowiki>#sginfo -c /dev/sda</nowiki><br /> which gives a list of attribute names and values
*# <nowiki>#sginfo -cX /dev/sda</nowiki><br /> which gives an array of cache values which you must match up with from step 1, e.g.<br /> 0 0 0 1 0 1 0 0 0 0 65535 0 65535 65535 1 0 0 0 3 0 0
*# <nowiki>#sginfo -cXR /dev/sda 0 0 0 1 0 0 0 0 0 0 65535 0 65535 65535 1 0 0 0 3 0 0</nowiki><br /> allows you to reset the value of the cache attributes.

For RAID controllers:

* See the section about RAID controllers below

This disabling is kept persistent for a SCSI disk. However, for a SATA/PATA disk this needs to be done after every reset as it will reset back to the default of the write cache enabled. And a reset can happen after reboot or on error recovery of the drive. This makes it rather difficult to guarantee that the write cache is maintained as disabled.<br />

=== Using an external log. ===

Some people have considered the idea of using an external log on a separate drive with the write cache disabled and the rest of the file system on another disk with the write cache enabled. However, that will '''not''' solve the problem. For example, the tail of the log is moved when we are notified that a metadata write is completed to disk and we won't be able to guarantee that if the metadata is on a drive with the write cache enabled.

In fact using an external log will disable XFS' write barrier support.

=== Write barrier support. ===

Write barrier support is enabled by default in XFS since kernel version 2.6.17. It is disabled by mounting the filesystem with "nobarrier". Barrier support will flush the write back cache at the appropriate times (such as on XFS log writes). This is generally the recommended solution, however, you should check the system logs to ensure it was successful. Barriers will be disabled and reported in the log if any of the 3 scenarios occurs:

* "Disabling barriers, not supported with external log device"
* "Disabling barriers, not supported by the underlying device"
* "Disabling barriers, trial barrier write failed"

If the filesystem is mounted with an external log device then we currently don't support flushing to the data and log devices (this may change in the future). If the driver tells the block layer that the device does not support write cache flushing with the write cache enabled then it will report that the device doesn't support it. And finally we will actually test out a barrier write on the superblock and test its error state afterwards, reporting if it fails.

== 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". But take care about the hard disk write cache, which should be off.

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

It's hard to tell because there are so many controllers. Please consult your RAID controller documentation to determine how to change these settings, but we try to give an overview here:

Real RAID controllers (not those found onboard of mainboards) normally have a battery backed cache (or an [http://en.wikipedia.org/wiki/Electric_double-layer_capacitor ultracapacitor] + flash memory "[http://www.tweaktown.com/articles/2800/adaptec_zero_maintenance_cache_protection_explained/ zero maintenance cache]") which is used for buffering writes to improve speed. Even if it's battery backed, the individual hard disk write caches need to be turned off, as they are not protected from a powerfail and will just lose all contents in that case.

* onboard RAID controllers: there are so many different types it's hard to tell. Generally, those controllers have no cache, but let the hard disk write cache on. That can lead to the bad situation that after a powerfail with RAID-1 when only parts of the disk cache have been written, the controller doesn't even see that the disks are out of sync, as the disks can resort cached blocks and might have saved the superblock info, but then lost different data contents. So, turn off disk write caches before using the RAID function.

* 3ware: /cX/uX set cache=off, see http://www.3ware.com/support/UserDocs/CLIGuide-9.5.1.1.pdf , page 86

* Adaptec: allows setting individual drives cache
arcconf setcache <disk> wb|wt
wb=write back, which means write cache on, wt=write through, which means write cache off. So "wt" should be chosen.

* Areca: In archttp under "System Controls" -> "System Configuration" there's the option "Disk Write Cache Mode" (defaults "Auto")

"Off": disk write cache is turned off

"On": disk write cache is enabled, this is not safe for your data but fast

"Auto": If you use a BBM (battery backup module, which you really should use if you care about your data), the controller automatically turns disk writes off, to protect your data. In case no BBM is attached, the controller switches to "On", because neither controller cache nor disk cache is safe so you don't seem to care about your data and just want high speed (which you get then).

That's a very sensible default so you can let it "Auto" or enforce "Off" to be sure.

* LSI MegaRAID: allows setting individual disks cache:
MegaCli -AdpCacheFlush -aN|-a0,1,2|-aALL # flushes the controller cache
MegaCli -LDGetProp -Cache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # shows the controller cache settings
MegaCli -LDGetProp -DskCache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # shows the disk cache settings (for all phys. disks in logical disk)
MegaCli -LDSetProp -EnDskCache|DisDskCache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # set disk cache setting

* Xyratex: from the docs: "Write cache includes the disk drive cache and controller cache.". So that means you can only set the drive caches and the unit caches together. To protect your data, turn it off, but write performance will suffer badly as also the controller write cache is disabled.

== Q: Which settings are best with virtualization like VMware, XEN, qemu? ==

The biggest problem is that those products seem to also virtualize disk
writes in a way that even barriers don't work any more, which means even
a fsync is not reliable. Tests confirm that unplugging the power from
such a system even with RAID controller with battery backed cache and
hard disk cache turned off (which is safe on a normal host) you can
destroy a database within the virtual machine (client, domU whatever you
call it).

In qemu you can specify cache=off on the line specifying the virtual
disk. For others information is missing.

== Q: What is the issue with directory corruption in Linux 2.6.17? ==

In the Linux kernel 2.6.17 release a subtle bug was accidentally introduced into the XFS directory code by some "sparse" endian annotations. This bug was sufficiently uncommon (it only affects a certain type of format change, in Node or B-Tree format directories, and only in certain situations) that it was not detected during our regular regression testing, but it has been observed in the wild by a number of people now.

''Update: the fix is included in 2.6.17.7 and later kernels.''

To add insult to injury, '''xfs_repair(8)''' is currently not correcting these directories on detection of this corrupt state either. This '''xfs_repair''' issue is actively being worked on, and a fixed version will be available shortly.

''Update: a fixed '''xfs_repair''' is now available; version 2.8.10 or later of the xfsprogs package contains the fixed version.''

No other kernel versions are affected. However, using a corrupt filesystem on other kernels can still result in the filesystem being shutdown if the problem has not been rectified (on disk), making it seem like other kernels are affected.

The '''xfs_check''' tool, or '''xfs_repair -n''', should be able to detect any directory corruption.

Until a fixed '''xfs_repair''' binary is available, one can make use of the '''xfs_db(8)''' command to mark the problem directory for removal (see the example below). A subsequent '''xfs_repair''' invocation will remove the directory and move all contents into "lost+found", named by inode number (see second example on how to map inode number to directory entry name, which needs to be done _before_ removing the directory itself). The inode number of the corrupt directory is included in the shutdown report issued by the kernel on detection of directory corruption. Using that inode number, this is how one would ensure it is removed:

<nowiki>
# xfs_db -x /dev/sdXXX
xfs_db> inode NNN
xfs_db> print
core.magic = 0x494e
core.mode = 040755
core.version = 2
core.format = 3 (btree)
...
xfs_db> write core.mode 0
xfs_db> quit
</nowiki>

A subsequent '''xfs_repair''' will clear the directory, and add new entries (named by inode number) in lost+found.

The easiest way to map inode numbers to full paths is via '''xfs_ncheck(8)'''<nowiki>: </nowiki>

<nowiki>
# xfs_ncheck -i 14101 -i 14102 /dev/sdXXX
14101 full/path/mumble_fratz_foo_bar_1495
14102 full/path/mumble_fratz_foo_bar_1494
</nowiki>

Should this not work, we can manually map inode numbers in B-Tree format directory by taking the following steps:

<nowiki>
# xfs_db -x /dev/sdXXX
xfs_db> inode NNN
xfs_db> print
core.magic = 0x494e
...
next_unlinked = null
u.bmbt.level = 1
u.bmbt.numrecs = 1
u.bmbt.keys[1] = [startoff] 1:[0]
u.bmbt.ptrs[1] = 1:3628
xfs_db> fsblock 3628
xfs_db> type bmapbtd
xfs_db> print
magic = 0x424d4150
level = 0
numrecs = 19
leftsib = null
rightsib = null
recs[1-19] = [startoff,startblock,blockcount,extentflag]
1:[0,3088,4,0] 2:[4,3128,8,0] 3:[12,3308,4,0] 4:[16,3360,4,0]
5:[20,3496,8,0] 6:[28,3552,8,0] 7:[36,3624,4,0] 8:[40,3633,4,0]
9:[44,3688,8,0] 10:[52,3744,4,0] 11:[56,3784,8,0]
12:[64,3840,8,0] 13:[72,3896,4,0] 14:[33554432,3092,4,0]
15:[33554436,3488,8,0] 16:[33554444,3629,4,0]
17:[33554448,3748,4,0] 18:[33554452,3900,4,0]
19:[67108864,3364,4,0]
</nowiki>

At this point we are looking at the extents that hold all of the directory information. There are three types of extent here, we have the data blocks (extents 1 through 13 above), then the leaf blocks (extents 14 through 18), then the freelist blocks (extent 19 above). The jumps in the first field (start offset) indicate our progression through each of the three types. For recovering file names, we are only interested in the data blocks, so we can now feed those offset numbers into the '''xfs_db''' dblock command. So, for the fifth extent - 5:[20,3496,8,0] - listed above:

...
xfs_db> dblock 20
xfs_db> print
dhdr.magic = 0x58443244
dhdr.bestfree[0].offset = 0
dhdr.bestfree[0].length = 0
dhdr.bestfree[1].offset = 0
dhdr.bestfree[1].length = 0
dhdr.bestfree[2].offset = 0
dhdr.bestfree[2].length = 0
du[0].inumber = 13937
du[0].namelen = 25
du[0].name = "mumble_fratz_foo_bar_1595"
du[0].tag = 0x10
du[1].inumber = 13938
du[1].namelen = 25
du[1].name = "mumble_fratz_foo_bar_1594"
du[1].tag = 0x38
...

So, here we can see that inode number 13938 matches up with name "mumble_fratz_foo_bar_1594". Iterate through all the extents, and extract all the name-to-inode-number mappings you can, as these will be useful when looking at "lost+found" (once '''xfs_repair''' has removed the corrupt directory).

== Q: Why does my > 2TB XFS partition disappear when I reboot ? ==

Strictly speaking this is not an XFS problem.

To support > 2TB partitions you need two things: a kernel that supports large block devices (<tt>CONFIG_LBD=y</tt>) and a partition table format that can hold large partitions. The default DOS partition tables don't. The best partition format for
> 2TB partitions is the EFI GPT format (<tt>CONFIG_EFI_PARTITION=y</tt>).

Without CONFIG_LBD=y you can't even create the filesystem, but without <tt>CONFIG_EFI_PARTITION=y</tt> it works fine until you reboot at which point the partition will disappear. Note that you need to enable the <tt>CONFIG_PARTITION_ADVANCED</tt> option before you can set <tt>CONFIG_EFI_PARTITION=y</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. To fix this, [http://oss.sgi.com/pipermail/xfs/2009-January/039835.html Dave Chinner advised]:

The only way to fix this is to move data around to free up space
below 1TB. Find your oldest data (i.e. that was around before even
the first grow) and move it off the filesystem (move, not copy).
Then if you copy it back on, the data blocks will end up above 1TB
and that should leave you with plenty of space for inodes below 1TB.

A complete dump and restore will also fix the problem ;)

Also, you can add 'inode64' to your mount options to allow inodes to live above 1TB.

example:[https://www.centos.org/modules/newbb/viewtopic.php?topic_id=30703&forum=38 | No space left on device on xfs filesystem with 7.7TB free]

== Q: Is using noatime or/and nodiratime at mount time giving any performance benefits in xfs (or not using them performance decrease)? ==

The default atime behaviour is relatime, which has almost no overhead compared to noatime but still maintains sane atime values. All Linux filesystems use this as the default now (since around 2.6.30), but XFS has used relatime-like behaviour since 2006, so no-one should really need to ever use noatime on XFS for performance reasons.

Also, noatime implies nodiratime, so there is never a need to specify nodiratime when noatime is also specified.

== Q: How to get around a bad inode repair is unable to clean up ==

The trick is go in with xfs_db and mark the inode as a deleted, which will cause repair to clean it up and finish the remove process.

xfs_db -x -c 'inode XXX' -c 'write core.nextents 0' -c 'write core.size 0' /dev/hdXX

== Q: How to calculate the correct sunit,swidth values for optimal performance ==

XFS allows to optimize for a given RAID stripe unit (stripe size) and stripe width (number of data disks) via mount options.

These options can be sometimes autodetected (for example with md raid and recent enough kernel (>= 2.6.32) and xfsprogs (>= 3.1.1) built with libblkid support) but manual calculation is needed for most of hardware raids.

The calculation of these values is quite simple:

su = <RAID controllers stripe size in BYTES (or KiBytes when used with k)>
sw = <# of data disks (don't count parity disks)>

So if your RAID controller has a stripe size of 64KB, and you have a RAID-6 with 8 disks, use

su = 64k
sw = 6 (RAID-6 of 8 disks has 6 data disks)

A RAID stripe size of 256KB with a RAID-10 over 16 disks should use

su = 256k
sw = 8 (RAID-10 of 16 disks has 8 data disks)

Alternatively, you can use "sunit" instead of "su" and "swidth" instead of "sw" but then sunit/swidth values need to be specified in "number of 512B sectors"!

Note that <tt>xfs_info</tt> and <tt>mkfs.xfs</tt> interpret sunit and swidth as being specified in units of 512B sectors; that's unfortunately not the unit they're reported in, however.
<tt>xfs_info</tt> and <tt>mkfs.xfs</tt> report them in multiples of your basic block size (bsize) and not in 512B sectors.

Assume for example: swidth 1024 (specified at mkfs.xfs command line; so 1024 of 512B sectors) and block size of 4096 (bsize reported by mkfs.xfs at output). You should see swidth 128 (reported by mkfs.xfs at output). 128 * 4096 == 1024 * 512.

When creating XFS filesystem on top of LVM on top of hardware raid please use sunit/swith values as when creating XFS filesystem directly on top of hardware raid.

== Q: Why doesn't NFS-exporting subdirectories of inode64-mounted filesystem work? ==

The default <tt>fsid</tt> type encodes only 32-bit of the inode number for subdirectory exports. However, exporting the root of the filesystem works, or using one of the non-default <tt>fsid</tt> types (<tt>fsid=uuid</tt> in <tt>/etc/exports</tt> with recent <tt>nfs-utils</tt>) should work as well. (Thanks, Christoph!)

== Q: What is the inode64 mount option for? ==

By default, with 32bit inodes, XFS places inodes only in the first 1TB of a disk. If you have a disk with 100TB, all inodes will be stuck in the first TB. This can lead to strange things like "disk full" when you still have plenty space free, but there's no more place in the first TB to create a new inode. Also, performance sucks.

To come around this, use the inode64 mount options for filesystems >1TB. Inodes will then be placed in the location where their data is, minimizing disk seeks.

Beware that some old programs might have problems reading 64bit inodes, especially over NFS. Your editor used inode64 for over a year with recent (openSUSE 11.1 and higher) distributions using NFS and Samba without any corruptions, so that might be a recent enough distro.

== Q: Can I just try the inode64 option to see if it helps me? ==

Starting from kernel 2.6.35, you can try and then switch back. Older kernels have a bug leading to strange problems if you mount without inode64 again. For example, you can't access files & dirs that have been created with an inode >32bit anymore.

== Q: Performance: mkfs.xfs -n size=64k option ==

Asking the implications of that mkfs option on the XFS mailing list, Dave Chinner explained it this way:

Inodes are not stored in the directory structure, only the directory entry name and the inode number. Hence the amount of space used by a
directory entry is determined by the length of the name.

There is extra overhead to allocate large directory blocks (16 pages instead of one, to begin with, then there's the vmap overhead, etc), so for small directories smaller block sizes are faster for create and unlink operations.

For empty directories, operations on 4k block sized directories consume roughly 50% less CPU that 64k block size directories. The 4k block size directories consume less CPU out to roughly 1.5 million entries where the two are roughly equal. At directory sizes of 10 million entries, 64k directory block operations are consuming about 15% of the CPU that 4k directory block operations consume.

In terms of lookups, the 64k block directory will take less IO but consume more CPU for a given lookup. Hence it depends on your IO latency and whether directory readahead can hide that latency as to which will be faster. e.g. For SSDs, CPU usage might be the limiting factor, not the IO. Right now I don't have any numbers on what the difference might be - I'm getting 1 billion inode population issues worked out first before I start on measuring cold cache lookup times on 1 billion files....

== Q: I want to tune my XFS filesystems for <something> ==

The standard answer you will get to this question is this: use the defaults.

There are few workloads where using non-default mkfs.xfs or mount options make much sense. In general, the default values already used are optimised for best performance in the first place. mkfs.xfs will detect the difference between single disk and MD/DM RAID setups and change the default values it uses to configure the filesystem appropriately.

There are a lot of "XFS tuning guides" that Google will find for you - most are old, out of date and full of misleading or just plain incorrect information. Don't expect that tuning your filesystem for optimal bonnie++ numbers will mean your workload will go faster. You should only consider changing the defaults if either: a) you know from experience that your workload causes XFS a specific problem that can be worked around via a configuration change, or b) your workload is demonstrating bad performance when using the default configurations. In this case, you need to understand why your application is causing bad performance before you start tweaking XFS configurations.

In most cases, the only thing you need to to consider for <tt>mkfs.xfs</tt> is specifying the stripe unit and width for hardware RAID devices. For mount options, the only thing that will change metadata performance considerably are the <tt>logbsize</tt> and <tt>delaylog</tt> mount options. Increasing <tt>logbsize</tt> reduces the number of journal IOs for a given workload, and <tt>delaylog</tt> will reduce them even further. The trade off for this increase in metadata performance is that more operations may be "missing" after recovery if the system crashes while actively making modifications.

== Q: Which factors influence the memory usage of xfs_repair? ==

This is best explained with an example. The example filesystem is 16Tb, but basically empty (look at icount).

# xfs_repair -n -vv -m 1 /dev/vda
Phase 1 - find and verify superblock...
- max_mem = 1024, icount = 64, imem = 0, dblock = 4294967296, dmem = 2097152
Required memory for repair is greater that the maximum specified
with the -m option. Please increase it to at least 2096.
#

xfs_repair is saying it needs at least 2096MB of RAM to repair the filesystem,
of which 2,097,152KB is needed for tracking free space.
(The -m 1 argument was telling xfs_repair to use ony 1 MB of memory.)

Now if we add some inodes (50 million) to the filesystem (look at icount again), and the result is:

# xfs_repair -vv -m 1 /dev/vda
Phase 1 - find and verify superblock...
- max_mem = 1024, icount = 50401792, imem = 196882, dblock = 4294967296, dmem = 2097152
Required memory for repair is greater that the maximum specified
with the -m option. Please increase it to at least 2289.

That is now needs at least another 200MB of RAM to run.

The numbers reported by xfs_repair are the absolute minimum required and approximate at that;
more RAM than this may be required to complete successfully.
Also, if you only give xfs_repair the minimum required RAM, it will be slow;
for best repair performance, the more RAM you can give it the better.

== Q: Why some files of my filesystem shows as "?????????? ? ? ? ? ? filename" ? ==

If ls -l shows you a listing as

# ?????????? ? ? ? ? ? file1
?????????? ? ? ? ? ? file2
?????????? ? ? ? ? ? file3
?????????? ? ? ? ? ? file4

and errors like:
# ls /pathtodir/
ls: cannot access /pathtodir/file1: Invalid argument
ls: cannot access /pathtodir/file2: Invalid argument
ls: cannot access /pathtodir/file3: Invalid argument
ls: cannot access /pathtodir/file4: Invalid argument

or even:
# failed to stat /pathtodir/file1

It is very probable your filesystem must be mounted with inode64
# mount -oremount,inode64 /dev/diskpart /mnt/xfs

should make it work ok again.
If it works, add the option to fstab.

XFS FAQ

2011-10-29T19:27:17Z

Ckujau: possible vandalism?

Info from: [http://oss.sgi.com/projects/xfs/faq.html main XFS faq at SGI]

Many thanks to earlier maintainers of this document - Thomas Graichen and Seth Mos.

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

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''.

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

Andreas Gruenbacher maintains the Extended Attribute and POSIX ACL documentation for Linux at http://acl.bestbits.at/

The '''acl(5)''' manual page is also quite extensive.

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

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.

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

Linux native filesystem (83).

== Q: What mount options does XFS have? ==

There are a number of mount options influencing XFS filesystems - refer to the '''mount(8)''' manual page or the documentation in the kernel source tree itself ([http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/xfs.txt;hb=HEAD Documentation/filesystems/xfs.txt])

== Q: Is there any relation between the XFS utilities and the kernel version? ==

No, there is no relation. Newer utilities tend to mainly have fixes and checks the previous versions might not have. New features are also added in a backward compatible way - if they are enabled via mkfs, an incapable (old) kernel will recognize that it does not understand the new feature, and refuse to mount the filesystem.

== Q: Does it run on platforms other than i386? ==

XFS runs on all of the platforms that Linux supports. It is more tested on the more common platforms, especially the i386 family. Its also well tested on the IA64 platform since thats the platform SGI Linux products use.

== Q: Quota: Do quotas work on XFS? ==

Yes.

To use quotas with XFS, you need to enable XFS quota support when you configure your kernel. You also need to specify quota support when mounting. You can get the Linux quota utilities at their sourceforge website [http://sourceforge.net/projects/linuxquota/ http://sourceforge.net/projects/linuxquota/] or use '''xfs_quota(8)'''.

== Q: Quota: What's project quota? ==

The project quota is a quota mechanism in XFS can be used to implement a form of directory tree quota, where a specified directory and all of the files and subdirectories below it (i.e. a tree) can be restricted to using a subset of the available space in the filesystem.

== Q: Quota: Can group quota and project quota be used at the same time? ==

No, project quota cannot be used with group quota at the same time. On the other hand user quota and project quota can be used simultaneously.

== Q: Quota: Is umounting prjquota (project quota) enabled fs and mounting it again with grpquota (group quota) removing prjquota limits previously set from fs (and vice versa) ? ==

To be answered.

== Q: Are there any dump/restore tools for XFS? ==

'''xfsdump(8)''' and '''xfsrestore(8)''' are fully supported. The tape format is the same as on IRIX, so tapes are interchangeable between operating systems.

== Q: Does LILO work with XFS? ==

This depends on where you install LILO.

Yes, for MBR (Master Boot Record) installations.

No, for root partition installations because the XFS superblock is written at block zero, where LILO would be installed. This is to maintain compatibility with the IRIX on-disk format, and will not be changed.

== Q: Does GRUB work with XFS? ==

There is native XFS filesystem support for GRUB starting with version 0.91 and onward. Unfortunately, GRUB used to make incorrect assumptions about being able to read a block device image while a filesystem is mounted and actively being written to, which could cause intermittent problems when using XFS. This has reportedly since been fixed, and the 0.97 version (at least) of GRUB is apparently stable.

== Q: Can XFS be used for a root filesystem? ==

Yes, with one caveat: Linux does not support an external XFS journal for the root filesystem via the "rootflags=" kernel parameter. To use an external journal for the root filesystem in Linux, an init ramdisk must mount the root filesystem with explicit "logdev=" specified. [http://mindplusplus.wordpress.com/2008/07/27/scratching-an-i.html More information here.]

== Q: Will I be able to use my IRIX XFS filesystems on Linux? ==

Yes. The on-disk format of XFS is the same on IRIX and Linux. Obviously, you should back-up your data before trying to move it between systems. Filesystems must be "clean" when moved (i.e. unmounted). If you plan to use IRIX filesystems on Linux keep the following points in mind: the kernel needs to have SGI partition support enabled; there is no XLV support in Linux, so you are unable to read IRIX filesystems which use the XLV volume manager; also not all blocksizes available on IRIX are available on Linux (only blocksizes less than or equal to the pagesize of the architecture: 4k for i386, ppc, ... 8k for alpha, sparc, ... is possible for now). Make sure that the directory format is version 2 on the IRIX filesystems (this is the default since IRIX 6.5.5). Linux can only read v2 directories.

== Q: Is there a way to make a XFS filesystem larger or smaller? ==

You can ''NOT'' make a XFS partition smaller online. The only way to shrink is to do a complete dump, mkfs and restore.

An XFS filesystem may be enlarged by using '''xfs_growfs(8)'''.

If using partitions, you need to have free space after this partition to do so. Remove partition, recreate it larger with the ''exact same'' starting point. Run '''xfs_growfs''' to make the partition larger. Note - editing partition tables is a dangerous pastime, so back up your filesystem before doing so.

Using XFS filesystems on top of a volume manager makes this a lot easier.

== Q: What information should I include when reporting a problem? ==

Things to include are what version of XFS you are using, if this is a CVS version of what date and version of the kernel. If you have problems with userland packages please report the version of the package you are using.

If the problem relates to a particular filesystem, the output from the '''xfs_info(8)''' command and any '''mount(8)''' options in use will also be useful to the developers.

If you experience an oops, please run it through '''ksymoops''' so that it can be interpreted.

If you have a filesystem that cannot be repaired, make sure you have xfsprogs 2.9.0 or later and run '''xfs_metadump(8)''' to capture the metadata (which obfuscates filenames and attributes to protect your privacy) and make the dump available for someone to analyse.

== Q: Mounting an XFS filesystem does not work - what is wrong? ==

If mount prints an error message something like:

mount: /dev/hda5 has wrong major or minor number

you either do not have XFS compiled into the kernel (or you forgot to load the modules) or you did not use the "-t xfs" option on mount or the "xfs" option in <tt>/etc/fstab</tt>.

If you get something like:

mount: wrong fs type, bad option, bad superblock on /dev/sda1,
or too many mounted file systems

Refer to your system log file (<tt>/var/log/messages</tt>) for a detailed diagnostic message from the kernel.

== Q: Does the filesystem have an undelete capability? ==

There is no [[undelete]] in XFS (so far).

However at least some XFS driver implementations do not wipe file information nodes completely so there are chance to recover files with specialized commercial closed source software like [http://www.ufsexplorer.com/rdr_xfs.php Raise Data Recovery for XFS].

In this kind of XFS driver implementation it does not re-use directory entries immediately so there are chance to get back
recently deleted files even with their real names.

[[xfs_irecover]] or [[xfsr]] may help too ( http://rzr.online.fr/q/recover provide a few links )

This applies to most recent Linux distributions (versions?), as well as to most popular NAS boxes that use embedded linux and XFS file system.

Anyway, the best is to always keep backups.

== Q: How can I backup a XFS filesystem and ACLs? ==

You can backup a XFS filesystem with utilities like '''xfsdump(8)''' and standard '''tar(1)''' for standard files. If you want to backup ACLs you will need to use '''xfsdump''' or [http://www.bacula.org/en/dev-manual/Current_State_Bacula.html Bacula] (> version 3.1.4) or [http://rsync.samba.org/ rsync] (>= version 3.0.0) to backup ACLs and EAs. '''xfsdump''' can also be integrated with [http://www.amanda.org/ amanda(8)].

== Q: I see applications returning error 990 or "Structure needs cleaning", what is wrong? ==

The error 990 stands for [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=blob;f=fs/xfs/linux-2.6/xfs_linux.h#l145 EFSCORRUPTED] which usually means XFS has detected a filesystem metadata problem and has shut the filesystem down to prevent further damage. Also, since about June 2006, we [http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commit;h=da2f4d679c8070ba5b6a920281e495917b293aa0 converted from EFSCORRUPTED/990 over to using EUCLEAN], "Structure needs cleaning."

The cause can be pretty much anything, unfortunately - filesystem, virtual memory manager, volume manager, device driver, or hardware.

There should be a detailed console message when this initially happens. The messages have important information giving hints to developers as to the earliest point that a problem was detected. It is there to protect your data.

You can use xfs_check and xfs_repair to remedy the problem (with the file system unmounted).

== Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? ==

Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1.

XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash.

Since XFS does not write data out immediately unless you tell it to with fsync, an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are looking at an inode which was flushed out, but whose data was not. Typically you'll find that the inode is not taking any space since all it has is a size but no extents allocated (try examining the file with the '''xfs_bmap(8)''' command).

== Q: What is the problem with the write cache on journaled filesystems? ==

Many drives use a write back cache in order to speed up the performance of writes. However, there are conditions such as power failure when the write cache memory is never flushed to the actual disk. Further, the drive can de-stage data from the write cache to the platters in any order that it chooses. This causes problems for XFS and journaled filesystems in general because they rely on knowing when a write has completed to the disk. They need to know that the log information has made it to disk before allowing metadata to go to disk. When the metadata makes it to disk then the transaction can effectively be deleted from the log resulting in movement of the tail of the log and thus freeing up some log space. So if the writes never make it to the physical disk, then the ordering is violated and the log and metadata can be lost, resulting in filesystem corruption.

With hard disk cache sizes of currently (Jan 2009) up to 32MB that can be a lot of valuable information. In a RAID with 8 such disks these adds to 256MB, and the chance of having filesystem metadata in the cache is so high that you have a very high chance of big data losses on a power outage.

With a single hard disk and barriers turned on (on=default), the drive write cache is flushed before and after a barrier is issued. A powerfail "only" loses data in the cache but no essential ordering is violated, and corruption will not occur.

With a RAID controller with battery backed controller cache and cache in write back mode, you should turn off barriers - they are unnecessary in this case, and if the controller honors the cache flushes, it will be harmful to performance. But then you *must* disable the individual hard disk write cache in order to ensure to keep the filesystem intact after a power failure. The method for doing this is different for each RAID controller. See the section about RAID controllers below.

== Q: How can I tell if I have the disk write cache enabled? ==

For SCSI/SATA:

* Look in dmesg(8) output for a driver line, such as:<br /> "SCSI device sda: drive cache: write back"
* <nowiki># sginfo -c /dev/sda | grep -i 'write cache' </nowiki>

For PATA/SATA (although for SATA this only works on a recent kernel with ATA command passthrough):

* <nowiki># hdparm -I /dev/sda</nowiki><br /> and look under "Enabled Supported" for "Write cache"

For RAID controllers:

* See the section about RAID controllers below

== Q: How can I address the problem with the disk write cache? ==

=== Disabling the disk write back cache. ===

For SATA/PATA(IDE): (although for SATA this only works on a recent kernel with ATA command passthrough):<br />

* <nowiki># hdparm -W0 /dev/sda</nowiki><br /> # hdparm -W0 /dev/hda
* <nowiki># blktool /dev/sda wcache off</nowiki><br /> # blktool /dev/hda wcache off

For SCSI:

* Using sginfo(8) which is a little tedious<br /> It takes 3 steps. For example:
*# <nowiki>#sginfo -c /dev/sda</nowiki><br /> which gives a list of attribute names and values
*# <nowiki>#sginfo -cX /dev/sda</nowiki><br /> which gives an array of cache values which you must match up with from step 1, e.g.<br /> 0 0 0 1 0 1 0 0 0 0 65535 0 65535 65535 1 0 0 0 3 0 0
*# <nowiki>#sginfo -cXR /dev/sda 0 0 0 1 0 0 0 0 0 0 65535 0 65535 65535 1 0 0 0 3 0 0</nowiki><br /> allows you to reset the value of the cache attributes.

For RAID controllers:

* See the section about RAID controllers below

This disabling is kept persistent for a SCSI disk. However, for a SATA/PATA disk this needs to be done after every reset as it will reset back to the default of the write cache enabled. And a reset can happen after reboot or on error recovery of the drive. This makes it rather difficult to guarantee that the write cache is maintained as disabled.<br />

=== Using an external log. ===

Some people have considered the idea of using an external log on a separate drive with the write cache disabled and the rest of the file system on another disk with the write cache enabled. However, that will '''not''' solve the problem. For example, the tail of the log is moved when we are notified that a metadata write is completed to disk and we won't be able to guarantee that if the metadata is on a drive with the write cache enabled.

In fact using an external log will disable XFS' write barrier support.

=== Write barrier support. ===

Write barrier support is enabled by default in XFS since kernel version 2.6.17. It is disabled by mounting the filesystem with "nobarrier". Barrier support will flush the write back cache at the appropriate times (such as on XFS log writes). This is generally the recommended solution, however, you should check the system logs to ensure it was successful. Barriers will be disabled and reported in the log if any of the 3 scenarios occurs:

* "Disabling barriers, not supported with external log device"
* "Disabling barriers, not supported by the underlying device"
* "Disabling barriers, trial barrier write failed"

If the filesystem is mounted with an external log device then we currently don't support flushing to the data and log devices (this may change in the future). If the driver tells the block layer that the device does not support write cache flushing with the write cache enabled then it will report that the device doesn't support it. And finally we will actually test out a barrier write on the superblock and test its error state afterwards, reporting if it fails.

== 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". But take care about the hard disk write cache, which should be off.

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

It's hard to tell because there are so many controllers. Please consult your RAID controller documentation to determine how to change these settings, but we try to give an overview here:

Real RAID controllers (not those found onboard of mainboards) normally have a battery backed cache (or an [http://en.wikipedia.org/wiki/Electric_double-layer_capacitor ultracapacitor] + flash memory "[http://www.tweaktown.com/articles/2800/adaptec_zero_maintenance_cache_protection_explained/ zero maintenance cache]") which is used for buffering writes to improve speed. Even if it's battery backed, the individual hard disk write caches need to be turned off, as they are not protected from a powerfail and will just lose all contents in that case.

* onboard RAID controllers: there are so many different types it's hard to tell. Generally, those controllers have no cache, but let the hard disk write cache on. That can lead to the bad situation that after a powerfail with RAID-1 when only parts of the disk cache have been written, the controller doesn't even see that the disks are out of sync, as the disks can resort cached blocks and might have saved the superblock info, but then lost different data contents. So, turn off disk write caches before using the RAID function.

* 3ware: /cX/uX set cache=off, see http://www.3ware.com/support/UserDocs/CLIGuide-9.5.1.1.pdf , page 86

* Adaptec: allows setting individual drives cache
arcconf setcache <disk> wb|wt
wb=write back, which means write cache on, wt=write through, which means write cache off. So "wt" should be chosen.

* Areca: In archttp under "System Controls" -> "System Configuration" there's the option "Disk Write Cache Mode" (defaults "Auto")

"Off": disk write cache is turned off

"On": disk write cache is enabled, this is not safe for your data but fast

"Auto": If you use a BBM (battery backup module, which you really should use if you care about your data), the controller automatically turns disk writes off, to protect your data. In case no BBM is attached, the controller switches to "On", because neither controller cache nor disk cache is safe so you don't seem to care about your data and just want high speed (which you get then).

That's a very sensible default so you can let it "Auto" or enforce "Off" to be sure.

* LSI MegaRAID: allows setting individual disks cache:
MegaCli -AdpCacheFlush -aN|-a0,1,2|-aALL # flushes the controller cache
MegaCli -LDGetProp -Cache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # shows the controller cache settings
MegaCli -LDGetProp -DskCache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # shows the disk cache settings (for all phys. disks in logical disk)
MegaCli -LDSetProp -EnDskCache|DisDskCache -LN|-L0,1,2|-LAll -aN|-a0,1,2|-aALL # set disk cache setting

* Xyratex: from the docs: "Write cache includes the disk drive cache and controller cache.". So that means you can only set the drive caches and the unit caches together. To protect your data, turn it off, but write performance will suffer badly as also the controller write cache is disabled.

== Q: Which settings are best with virtualization like VMware, XEN, qemu? ==

The biggest problem is that those products seem to also virtualize disk
writes in a way that even barriers don't work any more, which means even
a fsync is not reliable. Tests confirm that unplugging the power from
such a system even with RAID controller with battery backed cache and
hard disk cache turned off (which is safe on a normal host) you can
destroy a database within the virtual machine (client, domU whatever you
call it).

In qemu you can specify cache=off on the line specifying the virtual
disk. For others information is missing.

== Q: What is the issue with directory corruption in Linux 2.6.17? ==

In the Linux kernel 2.6.17 release a subtle bug was accidentally introduced into the XFS directory code by some "sparse" endian annotations. This bug was sufficiently uncommon (it only affects a certain type of format change, in Node or B-Tree format directories, and only in certain situations) that it was not detected during our regular regression testing, but it has been observed in the wild by a number of people now.

''Update: the fix is included in 2.6.17.7 and later kernels.''

To add insult to injury, '''xfs_repair(8)''' is currently not correcting these directories on detection of this corrupt state either. This '''xfs_repair''' issue is actively being worked on, and a fixed version will be available shortly.

''Update: a fixed '''xfs_repair''' is now available; version 2.8.10 or later of the xfsprogs package contains the fixed version.''

No other kernel versions are affected. However, using a corrupt filesystem on other kernels can still result in the filesystem being shutdown if the problem has not been rectified (on disk), making it seem like other kernels are affected.

The '''xfs_check''' tool, or '''xfs_repair -n''', should be able to detect any directory corruption.

Until a fixed '''xfs_repair''' binary is available, one can make use of the '''xfs_db(8)''' command to mark the problem directory for removal (see the example below). A subsequent '''xfs_repair''' invocation will remove the directory and move all contents into "lost+found", named by inode number (see second example on how to map inode number to directory entry name, which needs to be done _before_ removing the directory itself). The inode number of the corrupt directory is included in the shutdown report issued by the kernel on detection of directory corruption. Using that inode number, this is how one would ensure it is removed:

<nowiki>
# xfs_db -x /dev/sdXXX
xfs_db> inode NNN
xfs_db> print
core.magic = 0x494e
core.mode = 040755
core.version = 2
core.format = 3 (btree)
...
xfs_db> write core.mode 0
xfs_db> quit
</nowiki>

A subsequent '''xfs_repair''' will clear the directory, and add new entries (named by inode number) in lost+found.

The easiest way to map inode numbers to full paths is via '''xfs_ncheck(8)'''<nowiki>: </nowiki>

<nowiki>
# xfs_ncheck -i 14101 -i 14102 /dev/sdXXX
14101 full/path/mumble_fratz_foo_bar_1495
14102 full/path/mumble_fratz_foo_bar_1494
</nowiki>

Should this not work, we can manually map inode numbers in B-Tree format directory by taking the following steps:

<nowiki>
# xfs_db -x /dev/sdXXX
xfs_db> inode NNN
xfs_db> print
core.magic = 0x494e
...
next_unlinked = null
u.bmbt.level = 1
u.bmbt.numrecs = 1
u.bmbt.keys[1] = [startoff] 1:[0]
u.bmbt.ptrs[1] = 1:3628
xfs_db> fsblock 3628
xfs_db> type bmapbtd
xfs_db> print
magic = 0x424d4150
level = 0
numrecs = 19
leftsib = null
rightsib = null
recs[1-19] = [startoff,startblock,blockcount,extentflag]
1:[0,3088,4,0] 2:[4,3128,8,0] 3:[12,3308,4,0] 4:[16,3360,4,0]
5:[20,3496,8,0] 6:[28,3552,8,0] 7:[36,3624,4,0] 8:[40,3633,4,0]
9:[44,3688,8,0] 10:[52,3744,4,0] 11:[56,3784,8,0]
12:[64,3840,8,0] 13:[72,3896,4,0] 14:[33554432,3092,4,0]
15:[33554436,3488,8,0] 16:[33554444,3629,4,0]
17:[33554448,3748,4,0] 18:[33554452,3900,4,0]
19:[67108864,3364,4,0]
</nowiki>

At this point we are looking at the extents that hold all of the directory information. There are three types of extent here, we have the data blocks (extents 1 through 13 above), then the leaf blocks (extents 14 through 18), then the freelist blocks (extent 19 above). The jumps in the first field (start offset) indicate our progression through each of the three types. For recovering file names, we are only interested in the data blocks, so we can now feed those offset numbers into the '''xfs_db''' dblock command. So, for the fifth extent - 5:[20,3496,8,0] - listed above:

...
xfs_db> dblock 20
xfs_db> print
dhdr.magic = 0x58443244
dhdr.bestfree[0].offset = 0
dhdr.bestfree[0].length = 0
dhdr.bestfree[1].offset = 0
dhdr.bestfree[1].length = 0
dhdr.bestfree[2].offset = 0
dhdr.bestfree[2].length = 0
du[0].inumber = 13937
du[0].namelen = 25
du[0].name = "mumble_fratz_foo_bar_1595"
du[0].tag = 0x10
du[1].inumber = 13938
du[1].namelen = 25
du[1].name = "mumble_fratz_foo_bar_1594"
du[1].tag = 0x38
...

So, here we can see that inode number 13938 matches up with name "mumble_fratz_foo_bar_1594". Iterate through all the extents, and extract all the name-to-inode-number mappings you can, as these will be useful when looking at "lost+found" (once '''xfs_repair''' has removed the corrupt directory).

== Q: Why does my > 2TB XFS partition disappear when I reboot ? ==

Strictly speaking this is not an XFS problem.

To support > 2TB partitions you need two things: a kernel that supports large block devices (<tt>CONFIG_LBD=y</tt>) and a partition table format that can hold large partitions. The default DOS partition tables don't. The best partition format for
> 2TB partitions is the EFI GPT format (<tt>CONFIG_EFI_PARTITION=y</tt>).

Without CONFIG_LBD=y you can't even create the filesystem, but without <tt>CONFIG_EFI_PARTITION=y</tt> it works fine until you reboot at which point the partition will disappear. Note that you need to enable the <tt>CONFIG_PARTITION_ADVANCED</tt> option before you can set <tt>CONFIG_EFI_PARTITION=y</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. To fix this, [http://oss.sgi.com/pipermail/xfs/2009-January/039835.html Dave Chinner advised]:

The only way to fix this is to move data around to free up space
below 1TB. Find your oldest data (i.e. that was around before even
the first grow) and move it off the filesystem (move, not copy).
Then if you copy it back on, the data blocks will end up above 1TB
and that should leave you with plenty of space for inodes below 1TB.

A complete dump and restore will also fix the problem ;)

Also, you can add 'inode64' to your mount options to allow inodes to live above 1TB.

example:[https://www.centos.org/modules/newbb/viewtopic.php?topic_id=30703&forum=38 | No space left on device on xfs filesystem with 7.7TB free]

== Q: Is using noatime or/and nodiratime at mount time giving any performance benefits in xfs (or not using them performance decrease)? ==

The default atime behaviour is relatime, which has almost no overhead compared to noatime but still maintains sane atime values. All Linux filesystems use this as the default now (since around 2.6.30), but XFS has used relatime-like behaviour since 2006, so no-one should really need to ever use noatime on XFS for performance reasons.

Also, noatime implies nodiratime, so there is never a need to specify nodiratime when noatime is also specified.

== Q: How to get around a bad inode repair is unable to clean up ==

The trick is go in with xfs_db and mark the inode as a deleted, which will cause repair to clean it up and finish the remove process.

xfs_db -x -c 'inode XXX' -c 'write core.nextents 0' -c 'write core.size 0' /dev/hdXX

== Q: How to calculate the correct sunit,swidth values for optimal performance ==

XFS allows to optimize for a given RAID stripe unit (stripe size) and stripe width (number of data disks) via mount options.

These options can be sometimes autodetected (for example with md raid and recent enough kernel (>= 2.6.32) and xfsprogs (>= 3.1.1) built with libblkid support) but manual calculation is needed for most of hardware raids.

The calculation of these values is quite simple:

su = <RAID controllers stripe size in BYTES (or KiBytes when used with k)>
sw = <# of data disks (don't count parity disks)>

So if your RAID controller has a stripe size of 64KB, and you have a RAID-6 with 8 disks, use

su = 64k
sw = 6 (RAID-6 of 8 disks has 6 data disks)

A RAID stripe size of 256KB with a RAID-10 over 16 disks should use

su = 256k
sw = 8 (RAID-10 of 16 disks has 8 data disks)

Alternatively, you can use "sunit" instead of "su" and "swidth" instead of "sw" but then sunit/swidth values need to be specified in "number of 512B sectors"!

Note that <tt>xfs_info</tt> and <tt>mkfs.xfs</tt> interpret sunit and swidth as being specified in units of 512B sectors; that's unfortunately not the unit they're reported in, however.
<tt>xfs_info</tt> and <tt>mkfs.xfs</tt> report them in multiples of your basic block size (bsize) and not in 512B sectors.

Assume for example: swidth 1024 (specified at mkfs.xfs command line; so 1024 of 512B sectors) and block size of 4096 (bsize reported by mkfs.xfs at output). You should see swidth 128 (reported by mkfs.xfs at output). 128 * 4096 == 1024 * 512.

When creating XFS filesystem on top of LVM on top of hardware raid please use sunit/swith values as when creating XFS filesystem directly on top of hardware raid.

== Q: Why doesn't NFS-exporting subdirectories of inode64-mounted filesystem work? ==

The default <tt>fsid</tt> type encodes only 32-bit of the inode number for subdirectory exports. However, exporting the root of the filesystem works, or using one of the non-default <tt>fsid</tt> types (<tt>fsid=uuid</tt> in <tt>/etc/exports</tt> with recent <tt>nfs-utils</tt>) should work as well. (Thanks, Christoph!)

== Q: What is the inode64 mount option for? ==

By default, with 32bit inodes, XFS places inodes only in the first 1TB of a disk. If you have a disk with 100TB, all inodes will be stuck in the first TB. This can lead to strange things like "disk full" when you still have plenty space free, but there's no more place in the first TB to create a new inode. Also, performance sucks.

To come around this, use the inode64 mount options for filesystems >1TB. Inodes will then be placed in the location where their data is, minimizing disk seeks.

Beware that some old programs might have problems reading 64bit inodes, especially over NFS. Your editor used inode64 for over a year with recent (openSUSE 11.1 and higher) distributions using NFS and Samba without any corruptions, so that might be a recent enough distro.

== Q: Can I just try the inode64 option to see if it helps me? ==

Starting from kernel 2.6.35, you can try and then switch back. Older kernels have a bug leading to strange problems if you mount without inode64 again. For example, you can't access files & dirs that have been created with an inode >32bit anymore.

== Q: Performance: mkfs.xfs -n size=64k option ==

Asking the implications of that mkfs option on the XFS mailing list, Dave Chinner explained it this way:

Inodes are not stored in the directory structure, only the directory entry name and the inode number. Hence the amount of space used by a
directory entry is determined by the length of the name.

There is extra overhead to allocate large directory blocks (16 pages instead of one, to begin with, then there's the vmap overhead, etc), so for small directories smaller block sizes are faster for create and unlink operations.

For empty directories, operations on 4k block sized directories consume roughly 50% less CPU that 64k block size directories. The 4k block size directories consume less CPU out to roughly 1.5 million entries where the two are roughly equal. At directory sizes of 10 million entries, 64k directory block operations are consuming about 15% of the CPU that 4k directory block operations consume.

In terms of lookups, the 64k block directory will take less IO but consume more CPU for a given lookup. Hence it depends on your IO latency and whether directory readahead can hide that latency as to which will be faster. e.g. For SSDs, CPU usage might be the limiting factor, not the IO. Right now I don't have any numbers on what the difference might be - I'm getting 1 billion inode population issues worked out first before I start on measuring cold cache lookup times on 1 billion files....

== Q: I want to tune my XFS filesystems for <something> ==

The standard answer you will get to this question is this: use the defaults.

There are few workloads where using non-default mkfs.xfs or mount options make much sense. In general, the default values already used are optimised for best performance in the first place. mkfs.xfs will detect the difference between single disk and MD/DM RAID setups and change the default values it uses to configure the filesystem appropriately.

There are a lot of "XFS tuning guides" that Google will find for you - most are old, out of date and full of misleading or just plain incorrect information. Don't expect that tuning your filesystem for optimal bonnie++ numbers will mean your workload will go faster. You should only consider changing the defaults if either: a) you know from experience that your workload causes XFS a specific problem that can be worked around via a configuration change, or b) your workload is demonstrating bad performance when using the default configurations. In this case, you need to understand why your application is causing bad performance before you start tweaking XFS configurations.

In most cases, the only thing you need to to consider for <tt>mkfs.xfs</tt> is specifying the stripe unit and width for hardware RAID devices. For mount options, the only thing that will change metadata performance considerably are the <tt>logbsize</tt> and <tt>delaylog</tt> mount options. Increasing <tt>logbsize</tt> reduces the number of journal IOs for a given workload, and <tt>delaylog</tt> will reduce them even further. The trade off for this increase in metadata performance is that more operations may be "missing" after recovery if the system crashes while actively making modifications.

== Q: Which factors influence the memory usage of xfs_repair? ==

This is best explained with an example. The example filesystem is 16Tb, but basically empty (look at icount).

# xfs_repair -n -vv -m 1 /dev/vda
Phase 1 - find and verify superblock...
- max_mem = 1024, icount = 64, imem = 0, dblock = 4294967296, dmem = 2097152
Required memory for repair is greater that the maximum specified
with the -m option. Please increase it to at least 2096.
#

xfs_repair is saying it needs at least 2096MB of RAM to repair the filesystem,
of which 2,097,152KB is needed for tracking free space.
(The -m 1 argument was telling xfs_repair to use ony 1 MB of memory.)

Now if we add some inodes (50 million) to the filesystem (look at icount again), and the result is:

# xfs_repair -vv -m 1 /dev/vda
Phase 1 - find and verify superblock...
- max_mem = 1024, icount = 50401792, imem = 196882, dblock = 4294967296, dmem = 2097152
Required memory for repair is greater that the maximum specified
with the -m option. Please increase it to at least 2289.

That is now needs at least another 200MB of RAM to run.

The numbers reported by xfs_repair are the absolute minimum required and approximate at that;
more RAM than this may be required to complete successfully.
Also, if you only give xfs_repair the minimum required RAM, it will be slow;
for best repair performance, the more RAM you can give it the better.

User talk:J3gum

2011-10-13T19:31:10Z

Ckujau: /* De-pretty/complicate the page? */

== De-pretty/complicate the page? ==

Hi! I've seen your [http://xfs.org/index.php?title=Main_Page&diff=2356&oldid=2256 edit] to "De-pretty/complicate the page" and I don't understand why you did that? Don't we want our wiki to be pretty too? I don't think the page was overly complicated, just a few boxes so that one does not have to scroll down, as the page gets longer and longer. -- [[User:Ckujau|Ckujau]] 06:02, 12 October 2011 (UTC)

:First, I apologize if I've overstepped. That was not my intention. I did try to add [http://xfs.org/index.php?title=Main_Page&diff=2357&oldid=2356 a link and header] before the edit to which you referred. When added, the system generated table of contents overlapped the "custom box divisions". I added these two edits as two separate edits in case someone wanted to reimplement the "prettiness." I do believe these "prettiness" additions raise the bar for entry, that is not needed, for people trying to add content to the page. -- [[User:J3gum|J3gum]] 14:21, 12 October 2011 (UTC)

::No apology needed. I appreciate your addition and I agree that every formatting syntax (Mediawiki-syntax or HTML) inbetween context can confuse people who just want to add context. But the [[Main_Page]] is somewhat special, IMHO. It's an overview of the most important pages and I think we need to keep it somewhat organized and not every page needs to be on the front page. Otherwise we could just redirect to [[Special:AllPages]] :-) Every other page on this wiki needs only little formatting (just bullet points ("*") and paragraphs ("=="). I'd like to re-pretty the [[Main_Page]] again and keep [{{SERVER}}/index.php?title=Main_Page&action=watch watching] the page so if another additon mangles the "prettyness" I'll gladly fix it. Thanks. -- [[User:Ckujau|Ckujau]] 20:59, 12 October 2011 (UTC)

:::Yes, please add the "prettiness" back in. -- [[User:J3gum|J3gum]] 13:47, 13 October 2011 (UTC)

:::Please do not randomly edit front pages. If you think the format should be different please bring it up on the mailinglist. I really dislike the new look, but I'll give you the chance of getting more opinion on the mailinglist before simply reverting it. -- [[User:Hch|Hch]] 10:42, 13 October 2011 (UTC)

::::Please revert it, or better yet, add one in that doesn't break with the "auto-contents" menu. Either way is fine with me. -- [[User:J3gum|J3gum]] 13:47, 13 October 2011 (UTC)

::::: Done. -- [[User:Ckujau|Ckujau]] 19:31, 13 October 2011 (UTC)

== What change policy ==

Hch, you said, "bring it up on the mailinglist". If you want people to use your change policy, it may be a good idea to put your change policy in the description area on your homepage. Perhaps it should even have it's own page. It's pretty hard to guess the policy as a first time user. -- [[User:J3gum|J3gum]] 13:47, 13 October 2011 (UTC)

Main Page

2011-10-13T19:26:12Z

Ckujau: prettyness re-added, as per discussion

User:Ckujau

2011-10-12T21:06:14Z

Ckujau: rot13 :-)

rot13: ksfjvxv@areqolangher.qr

* [[/maintenance/]]

User talk:J3gum

2011-10-12T20:59:11Z

Ckujau: /* De-pretty/complicate the page? */

User talk:J3gum

2011-10-12T06:02:26Z

Ckujau: New page: == De-pretty/complicate the page? == Hi! I've seen your [http://xfs.org/index.php?title=Main_Page&diff=2356&oldid=2256 edit] to "De-pretty/complicate the page" and I don't understand why ...

Category:Template

2011-04-04T17:06:27Z

Ckujau: New page: Templates

Templates

Template:Delete

2011-04-04T17:05:44Z

Ckujau: category changed

{| class="wikitable" style="text-align:center; background:#ffaaaa"
|-
| '''This page has been labelled for deletion.'''<br/ >The given reason is: ''{{{1|specify reason}}}''.
|-
| <small>This normally means the page title is a bad one or the content may have been spam or a trojan trap. Senseful content possibly has been moved somewhere better.

If a page title is vaguely meaningful, the page should perhaps be a redirect, or hold a small summary for historical interest instead.

The page should now be empty apart from this message. Remember to check [[Special:Whatlinkshere/{{FULLPAGENAME}}|if anything links here]] and [{{fullurl:{{FULLPAGENAME}}|action=history}} the page history] before deleting. Please fix [[Special:Whatlinkshere/{{NAMESPACE}}:{{PAGENAME}}|any pages linking to here]].
</small>
|}

<includeonly>[[Category:Labelled for deletion]]</includeonly>
<noinclude>
== About this template - Procedure for deleting wiki pages ==
Use this template with the syntax:
<nowiki>{{delete|reason}}</nowiki>

Use it to delete a page, when a page definitely and unequivocally should be deleted:
: check the links to the page with "Special:WhatLinksHere", and correct the links in all linked pages
: '''Replace the entire contents of the page''' with <code><nowiki>{{delete|reason}}</nowiki></code>
: give a reason for the deletion in the 'Summary' field when you make this edit
: subscribe with <code><nowiki>--~~~~</nowiki></code>

See also [http://www.mediawiki.org/wiki/Help:Deleting_a_page MediaWiki Help:Deleting a page]

'''If the page title still holds some meaning''' but the contents of the page are mostly out-of-date or otherwise deserves deleting... well then fix it! Edit the page. Delete the content. Write something different in its place. Don't use this template.

All the pages get listed in [[:Category:Labelled for deletion]]. It will help the [[Special:listadmins|wiki sysops]] to deal with all these, if this delete template is only used in cases where the community has agreed upon the decision to delete, or where individuals believe (in good faith) that there could be no reason for anyone to disagree with the deletion.
</noinclude>

<noinclude>[[Category:Template]]</noinclude>

User:Ckujau/maintenance

2011-04-04T16:44:55Z

Ckujau: maintainer added

* [[Special:BrokenRedirects]]
* [[Special:DoubleRedirects]]
* [[Special:Lonelypages]]
* [[Special:Uncategorizedpages]]
* [[Special:Uncategorizedtemplates]]
* [[Special:Unusedcategories]]
* [[Special:Wantedcategories]]
* [[Special:Wantedpages]]

User:Ckujau

2011-04-04T16:44:34Z

Ckujau: maintenance added

[mailto:xfswiki@nerdbynature.de Christian Kujau]

* [[/maintenance/]]

XFS Companies

2010-10-03T08:30:41Z

Ckujau: s/Â/™/g

== These are companies that either use XFS or have a product that utilizes XFS . ==

Info gathered from: [http://oss.sgi.com/projects/xfs/users.html XFS Users] on [http://oss.sgi.com/ oss.sgi.com]

== [http://www.kernel.org/ The Linux Kernel Archives] ==

"A bit more than a year ago (as of October 2008) kernel.org, in an ever increasing need to squeeze more performance out of it's machines, made the leap of migrating the primary mirror machines (mirrors.kernel.org) to XFS. We site a number of reasons including fscking 5.5T of disk is long and painful, we were hitting various cache issues, and we were seeking better performance out of our file system."

"After initial tests looked positive we made the jump, and have been quite happy with the results. With an instant increase in performance and throughput, as well as the worst xfs_check we've ever seen taking 10 minutes, we were quite happy. Subsequently we've moved all primary mirroring file-systems to XFS, including www.kernel.org , and mirrors.kernel.org. With an average constant movement of about 400mbps around the world, and with peaks into the 3.1gbps range serving thousands of users simultaneously it's been a file system that has taken the brunt we can throw at it and held up spectacularly."

== [http://www.sdss.org/ The Sloan Digital Sky Survey] ==

"The Sloan Digital Sky Survey is an ambitious effort to map one-quarter of the sky at optical and very-near infrared wavelengths and take spectra of 1 million extra-galactic objects. The estimated amount of data that will be acquired over the 5 year lifespan of the project is 15TB, however, the total amount of storage space required for object informational databases, corrected frames, and reduced spectra will be several factors more than this. The goal is to have all the data online and available to the collaborators at all times. To accomplish this goal we are using commodity, off the shelf (COTS) Intel servers with EIDE disks configured as RAID50 arrays using XFS. Currently, 14 machines are in production accounting for over 18TB. By the scheduled end of the survey in 2005, 50TB of XFS disks will be online serving SDSS data to collaborators and the public."

"For complete details and status of the project please see [http://www.sdss.org/ http://www.sdss.org]. For details of the storage systems, see the [http://home.fnal.gov/~yocum/storageServerTechnicalNote.html SDSS Storage Server Technical Note]."

== [http://www-d0.fnal.gov/ The DØ Experiment at Fermilab] ==

"At the DØ experiment at the Fermi National Accelerator Laboratory we have a ~150 node cluster of desktop machines all using the SGI-patched kernel. Every large disk (>40Gb) or disk array in the cluster uses XFS including 4x640Gb disk servers and several 60-120Gb disks/arrays. Originally we chose reiserfs as our journaling filesystem, however, this was a disaster. We need to export these disks via NFS and this seemed perpetually broken in 2.4 series kernels. We switched to XFS and have been very happy. The only inconvenience is that it is not included in the standard kernel. The SGI guys are very prompt in their support of new kernels, but it is still an extra step which should not be necessary."

== [http://www.ciprico.com/pDiMeda.shtml Ciprico DiMeda NAS Solutions] ==

"The Ciprico DiMeda line of Network Attached Storage solutions combine the ease of connectivity of NAS with the SAN like performance levels required for digital media applications. The DiMeda 3600 provides high availability and high performance through dual NAS servers and redundant, scalable Fibre Channel RAID storage. The DiMeda 1700 provides high performance files services at a low price by using the latest Serial ATA RAID technology. All DiMeda systems are based on Linux and use XFS as the filesystem. We tested a number of filesystem alternatives and XFS was chosen because it provided the highest performance in digital media applications and the journaling feature ensures rapid failover in our dual node fault tolerant configurations."

== [http://www.quantum.com/Products/NAS+Servers/Guardian+14000/Default.htm The Quantum Guardian™ 14000] ==

"The Quantum Guardian™ 14000, the latest Network Attached Storage (NAS) solution from Quantum, delivers 1.4TB of enterprise-class storage for less than $25,000. The Guardian 14000 is a Linux-based device which utilizes XFS to provide a highly reliable journaling filesystem with simultaneous support for Windows, UNIX, Linux and Macintosh environments. As dedicated appliance optimized for fast, reliable file sharing, the Guardian 14000 combines the simplicity of NAS with a robust feature set designed for the most demanding enterprise environments. Support for tools such as Active Directory Service (ADS), UNIX Network Information Service (NIS) and Simple Network Management Protocol (SNMP) provides ease of management and seamless integration. Hardware redundancy, Snapshots and StorageCare™ on-site service ensure security for business-critical data."

== [http://www.bigstorage.com/products_approach_overview.html BigStorage K2~NAS] ==

"At BigStorage we pride ourselves on tailoring our NAS systems to meet our customer's needs, with the help of XFS we are able to provide them with the most reliable Journaling Filesystem technology available. Our open systems approach, which allows for cross-platform integration, gives our customers the flexibility to grow with their data requirements. In addition, BigStorage offers a variety of other features including total hardware redundancy, snapshotting, replication and backups directly from the unit. All of our products include BigStorageï¿½s 24/7 LiveResponse™ support. With LiveResponse™, we keep our team of experienced technical experts on call 24 hours a day, every day, to ensure that your storage investment remains online, all the time."

== [http://www.echostar.com Echostar DishPVR 721] ==

"Echostar uses the XFS filesystem for its latest generation of satellite receivers, the DP721. Echostar chose XFS for its performance, stability and unique set of features."

"XFS allowed us to meet a demanding requirement of recording two mpeg2 streams to the internal hard drive while simultaneously viewing a third pre-recorded stream. In addition, XFS allowed us to withstand unexpected power loss without filesystem corruption or user interaction."

"We tested several other filesystems, but XFS emerged as the clear winner."

== [http://www.sun.com/hardware/serverappliances/raq550/ Sun Cobalt RaQ™ 550] ==

From the [http://www.sun.com/hardware/serverappliances/raq550/features.html features] page:

"XFS is a journaling file system capable of quick fail over recovery after unexpected interruptions. XFS is an important feature for mission-critical applications as it ensures data integrity and dramatically reduces startup time by avoiding FSCK delay."

== [http://pingu.salk.edu/ Center for Cytometry and Molecular Imaging at the Salk Institute] ==

"I run the Center for Cytometry and Molecular Imaging at the Salk Institute in La Jolla, CA. We're a core facility for the Institute, offering flow cytometry, basic and deconvolution microscopy, phosphorimaging (radioactivity imaging) and fluorescent imaging."

"I'm currently in the process of migrating our data server to Linux/XFS. Our web server currently uses Linux/XFS. We have about 60 Gb on the data server which has a 100Gb SCSI RAID 5 array. This is a bit restrictive for our microscopists so in order that they can put more data online, I'm adding another machine, also running Linux/XFS, with about 420 Gb of IDE-RAID5, based on Adaptec controllers...."

"Servers are configured with quota and run Samba, NFS, and Netatalk for connectivity to the mixed bag of computers we have around here. I use the CVS XFS tree most of the time. I have not seen any problems in the several months I have been testing."

== [http://coltex.nl/ Coltex Retail Group BV] ==

"Coltex Retail group BV in the Netherlands uses Red Hat Linux with XFS for their main database server which collects the data from over 240 clothing retail stores throughout the Netherlands. Coltex depends on the availability of the server for over 100 hundred employees in the main office for retrieval of logistical and sales figures. The database size is roughly 10GB large containing both historical and current data."

"The entire production and logistical system depends on the availability of the system and downtime would mean a significant financial penalty. The speed and reliability of the XFS filesystem which has a proven track record and mature tools to go with it is fundamental to the availability of the system."

"XFS has saved us a lot of time during testing and implementation. A long filesystems check is no longer needed when bad things happen when they do. The increased speed of our database system which is based on Progress 9.1C is also a nice benefit to this filesystem."

== [http://www.dkp.com/ DKP Effects] ==

"We're a 3D computer graphics/post-production house. We've currently got four fileservers using XFS under Linux online - three 350GB servers and one 800GB server. The servers are under fairly heavy load - network load to and from the dual NICs on the box is basically maxed out 18 hours a day - and we do have occasional lockups and drive failures. Thanks to Linux SW RAID5 and XFS, though, we haven't had any data loss, or significant down time."

== [http://www.epigenomics.com/ Epigenomics] ==

"We currently have several IDE-to-SCSI-RAID systems with XFS in production. The largest has a capacity of 1.5TB, the other 2 have 430GB each."

"Data stored on these filesystems is on the one hand "normal" home directories and corporate documents and on the other hand scientific data for our laboratory and IT department."

== [http://www.incyte.com/ Incyte Genomics] ==

"I'm currently in the process of slowly converting 21 clusters totaling 2300+ processors over to XFS."

"These machines are running a fairly stock RH7.1+XFS. The application is our own custom scheduler for doing genomic research. We have one of the worlds largest sequencing labs which generates a tremendous amount of raw data. Vast amounts of CPU cycles must be applied to it to turn it into useful data we can then sell access to."

"Currently, a minority of these machines are running XFS, but as I can get downtime on the clusters I am upgrading them to 7.1+XFS. When I'm done, it'll be about 10TB of XFS goodness... across 9G disks mostly."

== [http://www.monmouth.edu/ Monmouth University] ==

"We've replaced our NetApp filer (80GB, $40,000). NetApp ONTAP software [runs on NetApp filers] is basically an NFS and CIFS server with their own proprietary filesystem. We were quickly running out of space and our annual budget almost depleted. What were we to do?"

"With an off-the-shelf Dell 4400 series server and 300GB of disks ($8,000 total). We were able to run Linux and Samba to emulate a NetApp filer."

"XFS allowed us to manage 300GB of data with absolutely no downtime (now going on 79 days) since implementation. Gone are the days of fearing the fsck of 300GB."

== [http://www.astro.wisc.edu The University of Wisconsin Astronomy Department] ==

"At the University of Wisconsin Astronomy Department we have been using Linux XFS since the first release. We currently have 31 Linux boxes running XFS on all filesystems with about 2.6 TB of disk space on these machines. We use XFS primarily on our data reduction systems, but we also use it on our web server and on one of the remote observing machines at the WIYN 3.5m Telescope at Kitt Peak (http://www.noao.edu/wiyn/wiyn.html)."

"We will likely be using Linux XFS at least in part on the GLIMPSE program (http://www.astro.wisc.edu/sirtf/) which will likely require several TB of disk space to process the data."

== [http://www.amoa.org/ The Austin Museum of Art] ==

"The Austin Museum of Art has two file servers running RedHat 7.2_XFS upgraded from RedHat 7.1_XFS. Our webserver runs Domino on top of RedHat 7.3_XFS and we're getting about 70% better performance than the Domino server running on Windows 2000 Server. We're moving our workstations away from Windows and Microsoft Office to an LTSP server running on RedHat 7.3_XFS.

"We've become solely dependent on XFS for all of our data systems."

== [http://www.tecmath.com/ tecmath AG] ==

"We use a production server with a 270 GB RAID 5 (hardware) disk array. It is based on a Suse 7.2 distribution, but with a standard 2.4.12 kernel with XFS and LVM patches. The server provides NFS to 8 Unix clients as well as Samba to about 80 PCs. The machine also runs Bind 9, Apache, Exim, DHCP, POP3, MySQL. I have tried out different configurations with ReiserFS, but I didn't manage to find a stable configuration with respect to NFS. Since I converted all disks to XFS some 3 months ago, we never had any filesystem-related problems."

== [http://www.theiqgroup.com/ The IQ Group] ==

"Here at the IQ Group, Inc. we use XFS for all our production and development servers."

"Our OS of choice is Slackware Linux 8.0. Our hardware of choice is Dell and VALinux servers."

"As for applications, we run the standard Unix/Linux apps like Sendmail, Apache, BIND, DHCP, iptables, etc.; as well as Oracle 9i and Arkeia."

"We've been running XFS across the board for about 3 months now without a hitch (so far)."

"Size-wise, our biggest server is about 40 GB, but that will be increasing substantially in the near future."

"Our production servers are collocated so a journaled FS was a must. Reboots are quick and no human interaction is required like with a bad fsck on ext2. Additionally, our database servers gain additional integrity and robustness."

"We originally chose XFS over ReiserFS and ext3 because of it's age (it's been in production on SGI boxes for probably longer than all the other journaling FS's combined) and it's speed appeared comparable as well."

== [http://www.artsit.usyd.edu.au Arts IT Unit, Sydney University] ==

"I've got XFS on a 'production' file server. The machine could have up to 500 people logged in, but typically less than 200. Most are Mac users, connected via NetAtalk for 'personal files', although there are shared areas for admin units. Probably about 30-40 windows users. (Samba) It's the file server for an Academic faculty at a University."

"Hardware RAID, via Mylex dual channel controller with 4 drives, Intel Tupelo MB, Intel 'SC5000' server chassis with redundant power and hot-swap scsi bays. The system boots off a non RAID single 9gb UW-scsi drive."

"Only system 'crash' was caused by some one accidentally unplugging it, just before we put it into production. It was back in full operation within 5 minutes. Without journaling, the fsck would have taken well over an hour. In day to day use it has run well."

== [http://structbio.vanderbilt.edu/comp/ Vanderbilt University Center for Structural Biology] ==

"I run a high-performance computing center for Structural Biology research at Vanderbilt University. We use XFS extensively, and have been since the late prerelease versions. I've had nothing but good experiences with it."

"We began using XFS in our search for a good solution for our RAID fileservers. We had such good experiences with it on these systems that we've begun putting it on the root/usr/var partitions of every Linux system we run here. I even have it on my laptop these days. XFS in combination with the 2.4 NFS3 implementation performs very well for us, and we have great uptimes on these systems (Our 750GB ArenaII setup is at 143 days right now)."

"All told, we've got about 1.2TB of XFS filesystems spinning right now. It's spread out across maybe a dozen or so filesystems and will continue to increase as we are growing fast and that's all we use now. Next up is putting it on our 17-node Linux cluster, which will bring that up to 1.5TB spread across 30 filesystems."

"I, for one, would LOVE to see XFS make it into the kernel tree. From my perspectives, it's one of the best things to happen to Linux in the 7 years I've been using/administering it."

==== 2008 Update ====

"We've since moved our main home directories to a proprietary NAS, but continue to use XFS on 10TB of LVM storage for doing backup-to-disk from the same NAS"

== [http://www-cdf.fnal.gov/ CDF Experiment at Fermi National Lab] ==

CDF, an elementary particle physics experiment at Fermi National Lab, is using XFS for all our cache disks.

The usage model is that we have a PB tape archive (2 STK silos) as permanent storage. In front of this archive we are deploying a roughly 100TB disk cache system. The cache is made up of 50 2TB file server based on cheap commodity hardware (3ware based hardware raid using IDE drives). The data is then processed by a cluster of 300 Dual CPU Linux PC's. The cache software is dCache, a DESY/FNAL product.

The whole system is used by more than 300 active users from all over the world for batch processing for their physics data analysis.

== [http://www.get2chip.com Get2Chip, Inc.] ==

"We are using XFS on 3 production file servers with approximately 1.5T of data. Quite impressive especially when we had a power outage and all three servers shutdown. All servers came back up in minutes with no problems! We are looking at creating two more servers that would manage 2+ TB of data store."

== [http://www.lando.co.za Lando International Group Technologies] ==

Lando International Group Technologies is the home of:

* [www.lando.co.za Lanndo Technologies Africa (Pty) Ltd] - Internet Service Provider
* [www.lbsd.net Linux Based Systems Design] (Article 21). Not-For-Profit company established to provide free Linux distributions and programs.
* Cell Park South Africa (Pty) Ltd. RSA Pat Appln 2001/10406. Collecting parking fees by means of cell phone SMS or voice.
* Read Plus Education (Pty) Ltd. Software based reading skills training and testing for ages 4 to 100.
* Mobivan. Mobile office including Internet access, fax, copying, printing, telephone, collection and delivery services, legal services, pre-paid phone and electricity services, bill payment email, secretarial services, training facilities and management services.
* Lando International Marketing Agency. Direct marketing services, design and supply of promotional material, consulting, sourcing of capital and other funding.
* Illico. Software development and systems analysis on most platforms.

"Throughout these companies, we use the XFS filesystem with [http://idms.lbsd.net IDMS Linux] on high-end Intel servers, with an average of 100 GB storage each. XFS stores our customer and user data, including credit card details, mail, routing tables, etc.. We have not had one problem since the release of the first XFS patch."

== [http://www.fcb-wilkens.com Foote, Cone, & Belding] ==

"We are an advertisement company in Germany, and the use of the XFS filesystem is a story of success for us. In our Hamburg office, we have two file servers having a 420 Gig RAID in XFS format serving (almost) all our data to about 180 Macs and about 30 PCs using Samba and Netatalk. Some of the data is used in our offices in Frankfurt and Berlin, and in fact the Berlin office is just getting it's own 250 Gig fileserver (using XFS) right now."

"The general success with XFS has led us to switch over all our Linux servers to run on XFS as well (with the exception of two systems that are tied to tight specifications configuration wise). XFS, even the old 1.0 version, has happily taken on various abuse - broken SCSI controllers, broken RAID systems."

== [http://www.moving-picture.co.uk/ Moving Picture Company] ==

"We here at MPC use XFS/RedHat 7.2 on all of our graphics-workstations and file-servers. More info can be found in an [http://www.linuxuser.co.uk/articles/issue20/lu20-Linux_at_work-In_the_picture.pdf article] LinuxUser magazine did on us recently."

== [http://www.coremetrics.com/ Coremetrics, Inc.] ==

"We are currently using XFS for 25+ production web-servers, ~900GB Oracle db servers, with potentially 15+ more servers by mid 2003, with ~900GB+ databases. All XFS installed."

"Also, our dev environment, except for the Sun boxes which all are being migrated to X86 in the aforementioned server additions, plus the dev Sun boxes as well, are all x86 dual proc servers running Oracle, application servers, or web services as needed. All servers run XFS from images we've got on our SystemImager servers."

"All production back-end servers are connected via FC1 or FC2 to a SAN containing ~13TB of raw storage, which, will soon be converted from VxFS to XFS with the migration of Oracle to our x86 platforms."

== [http://evolt.org Evolt.org] ==

"evolt.org, a world community for web developers promoting the mutual free exchange of ideas, skills and experiences, has had a great deal of success using XFS. Our primary webserver which serves 100K hosts/month, primary Oracle database with ~25Gb of data, and free member hosting for 1000 users haven't had a minute of downtime since XFS has been installed. Performance has been spectacular and maintenance a breeze."

<font size="-1"> ''All testimonials on this page represent the views of the submitters, and references to other products and companies should not be construed as an endorsement by either the organizations profiled, or by SGI. All trademarks (r) their respective owners.'' </font>

XFS Companies

2010-10-03T08:29:03Z

Ckujau: s/Â/™/

== These are companies that either use XFS or have a product that utilizes XFS . ==

Info gathered from: [http://oss.sgi.com/projects/xfs/users.html XFS Users] on [http://oss.sgi.com/ oss.sgi.com]

== [http://www.kernel.org/ The Linux Kernel Archives] ==

"A bit more than a year ago (as of October 2008) kernel.org, in an ever increasing need to squeeze more performance out of it's machines, made the leap of migrating the primary mirror machines (mirrors.kernel.org) to XFS. We site a number of reasons including fscking 5.5T of disk is long and painful, we were hitting various cache issues, and we were seeking better performance out of our file system."

"After initial tests looked positive we made the jump, and have been quite happy with the results. With an instant increase in performance and throughput, as well as the worst xfs_check we've ever seen taking 10 minutes, we were quite happy. Subsequently we've moved all primary mirroring file-systems to XFS, including www.kernel.org , and mirrors.kernel.org. With an average constant movement of about 400mbps around the world, and with peaks into the 3.1gbps range serving thousands of users simultaneously it's been a file system that has taken the brunt we can throw at it and held up spectacularly."

== [http://www.sdss.org/ The Sloan Digital Sky Survey] ==

"The Sloan Digital Sky Survey is an ambitious effort to map one-quarter of the sky at optical and very-near infrared wavelengths and take spectra of 1 million extra-galactic objects. The estimated amount of data that will be acquired over the 5 year lifespan of the project is 15TB, however, the total amount of storage space required for object informational databases, corrected frames, and reduced spectra will be several factors more than this. The goal is to have all the data online and available to the collaborators at all times. To accomplish this goal we are using commodity, off the shelf (COTS) Intel servers with EIDE disks configured as RAID50 arrays using XFS. Currently, 14 machines are in production accounting for over 18TB. By the scheduled end of the survey in 2005, 50TB of XFS disks will be online serving SDSS data to collaborators and the public."

"For complete details and status of the project please see [http://www.sdss.org/ http://www.sdss.org]. For details of the storage systems, see the [http://home.fnal.gov/~yocum/storageServerTechnicalNote.html SDSS Storage Server Technical Note]."

== [http://www-d0.fnal.gov/ The DØ Experiment at Fermilab] ==

"At the DØ experiment at the Fermi National Accelerator Laboratory we have a ~150 node cluster of desktop machines all using the SGI-patched kernel. Every large disk (>40Gb) or disk array in the cluster uses XFS including 4x640Gb disk servers and several 60-120Gb disks/arrays. Originally we chose reiserfs as our journaling filesystem, however, this was a disaster. We need to export these disks via NFS and this seemed perpetually broken in 2.4 series kernels. We switched to XFS and have been very happy. The only inconvenience is that it is not included in the standard kernel. The SGI guys are very prompt in their support of new kernels, but it is still an extra step which should not be necessary."

== [http://www.ciprico.com/pDiMeda.shtml Ciprico DiMeda NAS Solutions] ==

"The Ciprico DiMeda line of Network Attached Storage solutions combine the ease of connectivity of NAS with the SAN like performance levels required for digital media applications. The DiMeda 3600 provides high availability and high performance through dual NAS servers and redundant, scalable Fibre Channel RAID storage. The DiMeda 1700 provides high performance files services at a low price by using the latest Serial ATA RAID technology. All DiMeda systems are based on Linux and use XFS as the filesystem. We tested a number of filesystem alternatives and XFS was chosen because it provided the highest performance in digital media applications and the journaling feature ensures rapid failover in our dual node fault tolerant configurations."

== [http://www.quantum.com/Products/NAS+Servers/Guardian+14000/Default.htm The Quantum Guardian™ 14000] ==

"The Quantum Guardian™ 14000, the latest Network Attached Storage (NAS) solution from Quantum, delivers 1.4TB of enterprise-class storage for less than $25,000. The Guardian 14000 is a Linux-based device which utilizes XFS to provide a highly reliable journaling filesystem with simultaneous support for Windows, UNIX, Linux and Macintosh environments. As dedicated appliance optimized for fast, reliable file sharing, the Guardian 14000 combines the simplicity of NAS with a robust feature set designed for the most demanding enterprise environments. Support for tools such as Active Directory Service (ADS), UNIX Network Information Service (NIS) and Simple Network Management Protocol (SNMP) provides ease of management and seamless integration. Hardware redundancy, Snapshots and StorageCareÂ on-site service ensure security for business-critical data."

== [http://www.bigstorage.com/products_approach_overview.html BigStorage K2~NAS] ==

"At BigStorage we pride ourselves on tailoring our NAS systems to meet our customer's needs, with the help of XFS we are able to provide them with the most reliable Journaling Filesystem technology available. Our open systems approach, which allows for cross-platform integration, gives our customers the flexibility to grow with their data requirements. In addition, BigStorage offers a variety of other features including total hardware redundancy, snapshotting, replication and backups directly from the unit. All of our products include BigStorageï¿½s 24/7 LiveResponseÂ support. With LiveResponseÂ, we keep our team of experienced technical experts on call 24 hours a day, every day, to ensure that your storage investment remains online, all the time."

== [http://www.echostar.com Echostar DishPVR 721] ==

"Echostar uses the XFS filesystem for its latest generation of satellite receivers, the DP721. Echostar chose XFS for its performance, stability and unique set of features."

"XFS allowed us to meet a demanding requirement of recording two mpeg2 streams to the internal hard drive while simultaneously viewing a third pre-recorded stream. In addition, XFS allowed us to withstand unexpected power loss without filesystem corruption or user interaction."

"We tested several other filesystems, but XFS emerged as the clear winner."

== [http://www.sun.com/hardware/serverappliances/raq550/ Sun Cobalt RaQÂ 550] ==

From the [http://www.sun.com/hardware/serverappliances/raq550/features.html features] page:

"XFS is a journaling file system capable of quick fail over recovery after unexpected interruptions. XFS is an important feature for mission-critical applications as it ensures data integrity and dramatically reduces startup time by avoiding FSCK delay."

== [http://pingu.salk.edu/ Center for Cytometry and Molecular Imaging at the Salk Institute] ==

"I run the Center for Cytometry and Molecular Imaging at the Salk Institute in La Jolla, CA. We're a core facility for the Institute, offering flow cytometry, basic and deconvolution microscopy, phosphorimaging (radioactivity imaging) and fluorescent imaging."

"I'm currently in the process of migrating our data server to Linux/XFS. Our web server currently uses Linux/XFS. We have about 60 Gb on the data server which has a 100Gb SCSI RAID 5 array. This is a bit restrictive for our microscopists so in order that they can put more data online, I'm adding another machine, also running Linux/XFS, with about 420 Gb of IDE-RAID5, based on Adaptec controllers...."

"Servers are configured with quota and run Samba, NFS, and Netatalk for connectivity to the mixed bag of computers we have around here. I use the CVS XFS tree most of the time. I have not seen any problems in the several months I have been testing."

== [http://coltex.nl/ Coltex Retail Group BV] ==

"Coltex Retail group BV in the Netherlands uses Red Hat Linux with XFS for their main database server which collects the data from over 240 clothing retail stores throughout the Netherlands. Coltex depends on the availability of the server for over 100 hundred employees in the main office for retrieval of logistical and sales figures. The database size is roughly 10GB large containing both historical and current data."

"The entire production and logistical system depends on the availability of the system and downtime would mean a significant financial penalty. The speed and reliability of the XFS filesystem which has a proven track record and mature tools to go with it is fundamental to the availability of the system."

"XFS has saved us a lot of time during testing and implementation. A long filesystems check is no longer needed when bad things happen when they do. The increased speed of our database system which is based on Progress 9.1C is also a nice benefit to this filesystem."

== [http://www.dkp.com/ DKP Effects] ==

"We're a 3D computer graphics/post-production house. We've currently got four fileservers using XFS under Linux online - three 350GB servers and one 800GB server. The servers are under fairly heavy load - network load to and from the dual NICs on the box is basically maxed out 18 hours a day - and we do have occasional lockups and drive failures. Thanks to Linux SW RAID5 and XFS, though, we haven't had any data loss, or significant down time."

== [http://www.epigenomics.com/ Epigenomics] ==

"We currently have several IDE-to-SCSI-RAID systems with XFS in production. The largest has a capacity of 1.5TB, the other 2 have 430GB each."

"Data stored on these filesystems is on the one hand "normal" home directories and corporate documents and on the other hand scientific data for our laboratory and IT department."

== [http://www.incyte.com/ Incyte Genomics] ==

"I'm currently in the process of slowly converting 21 clusters totaling 2300+ processors over to XFS."

"These machines are running a fairly stock RH7.1+XFS. The application is our own custom scheduler for doing genomic research. We have one of the worlds largest sequencing labs which generates a tremendous amount of raw data. Vast amounts of CPU cycles must be applied to it to turn it into useful data we can then sell access to."

"Currently, a minority of these machines are running XFS, but as I can get downtime on the clusters I am upgrading them to 7.1+XFS. When I'm done, it'll be about 10TB of XFS goodness... across 9G disks mostly."

== [http://www.monmouth.edu/ Monmouth University] ==

"We've replaced our NetApp filer (80GB, $40,000). NetApp ONTAP software [runs on NetApp filers] is basically an NFS and CIFS server with their own proprietary filesystem. We were quickly running out of space and our annual budget almost depleted. What were we to do?"

"With an off-the-shelf Dell 4400 series server and 300GB of disks ($8,000 total). We were able to run Linux and Samba to emulate a NetApp filer."

"XFS allowed us to manage 300GB of data with absolutely no downtime (now going on 79 days) since implementation. Gone are the days of fearing the fsck of 300GB."

== [http://www.astro.wisc.edu The University of Wisconsin Astronomy Department] ==

"At the University of Wisconsin Astronomy Department we have been using Linux XFS since the first release. We currently have 31 Linux boxes running XFS on all filesystems with about 2.6 TB of disk space on these machines. We use XFS primarily on our data reduction systems, but we also use it on our web server and on one of the remote observing machines at the WIYN 3.5m Telescope at Kitt Peak (http://www.noao.edu/wiyn/wiyn.html)."

"We will likely be using Linux XFS at least in part on the GLIMPSE program (http://www.astro.wisc.edu/sirtf/) which will likely require several TB of disk space to process the data."

== [http://www.amoa.org/ The Austin Museum of Art] ==

"The Austin Museum of Art has two file servers running RedHat 7.2_XFS upgraded from RedHat 7.1_XFS. Our webserver runs Domino on top of RedHat 7.3_XFS and we're getting about 70% better performance than the Domino server running on Windows 2000 Server. We're moving our workstations away from Windows and Microsoft Office to an LTSP server running on RedHat 7.3_XFS.

"We've become solely dependent on XFS for all of our data systems."

== [http://www.tecmath.com/ tecmath AG] ==

"We use a production server with a 270 GB RAID 5 (hardware) disk array. It is based on a Suse 7.2 distribution, but with a standard 2.4.12 kernel with XFS and LVM patches. The server provides NFS to 8 Unix clients as well as Samba to about 80 PCs. The machine also runs Bind 9, Apache, Exim, DHCP, POP3, MySQL. I have tried out different configurations with ReiserFS, but I didn't manage to find a stable configuration with respect to NFS. Since I converted all disks to XFS some 3 months ago, we never had any filesystem-related problems."

== [http://www.theiqgroup.com/ The IQ Group] ==

"Here at the IQ Group, Inc. we use XFS for all our production and development servers."

"Our OS of choice is Slackware Linux 8.0. Our hardware of choice is Dell and VALinux servers."

"As for applications, we run the standard Unix/Linux apps like Sendmail, Apache, BIND, DHCP, iptables, etc.; as well as Oracle 9i and Arkeia."

"We've been running XFS across the board for about 3 months now without a hitch (so far)."

"Size-wise, our biggest server is about 40 GB, but that will be increasing substantially in the near future."

"Our production servers are collocated so a journaled FS was a must. Reboots are quick and no human interaction is required like with a bad fsck on ext2. Additionally, our database servers gain additional integrity and robustness."

"We originally chose XFS over ReiserFS and ext3 because of it's age (it's been in production on SGI boxes for probably longer than all the other journaling FS's combined) and it's speed appeared comparable as well."

== [http://www.artsit.usyd.edu.au Arts IT Unit, Sydney University] ==

"I've got XFS on a 'production' file server. The machine could have up to 500 people logged in, but typically less than 200. Most are Mac users, connected via NetAtalk for 'personal files', although there are shared areas for admin units. Probably about 30-40 windows users. (Samba) It's the file server for an Academic faculty at a University."

"Hardware RAID, via Mylex dual channel controller with 4 drives, Intel Tupelo MB, Intel 'SC5000' server chassis with redundant power and hot-swap scsi bays. The system boots off a non RAID single 9gb UW-scsi drive."

"Only system 'crash' was caused by some one accidentally unplugging it, just before we put it into production. It was back in full operation within 5 minutes. Without journaling, the fsck would have taken well over an hour. In day to day use it has run well."

== [http://structbio.vanderbilt.edu/comp/ Vanderbilt University Center for Structural Biology] ==

"I run a high-performance computing center for Structural Biology research at Vanderbilt University. We use XFS extensively, and have been since the late prerelease versions. I've had nothing but good experiences with it."

"We began using XFS in our search for a good solution for our RAID fileservers. We had such good experiences with it on these systems that we've begun putting it on the root/usr/var partitions of every Linux system we run here. I even have it on my laptop these days. XFS in combination with the 2.4 NFS3 implementation performs very well for us, and we have great uptimes on these systems (Our 750GB ArenaII setup is at 143 days right now)."

"All told, we've got about 1.2TB of XFS filesystems spinning right now. It's spread out across maybe a dozen or so filesystems and will continue to increase as we are growing fast and that's all we use now. Next up is putting it on our 17-node Linux cluster, which will bring that up to 1.5TB spread across 30 filesystems."

"I, for one, would LOVE to see XFS make it into the kernel tree. From my perspectives, it's one of the best things to happen to Linux in the 7 years I've been using/administering it."

==== 2008 Update ====

"We've since moved our main home directories to a proprietary NAS, but continue to use XFS on 10TB of LVM storage for doing backup-to-disk from the same NAS"

== [http://www-cdf.fnal.gov/ CDF Experiment at Fermi National Lab] ==

CDF, an elementary particle physics experiment at Fermi National Lab, is using XFS for all our cache disks.

The usage model is that we have a PB tape archive (2 STK silos) as permanent storage. In front of this archive we are deploying a roughly 100TB disk cache system. The cache is made up of 50 2TB file server based on cheap commodity hardware (3ware based hardware raid using IDE drives). The data is then processed by a cluster of 300 Dual CPU Linux PC's. The cache software is dCache, a DESY/FNAL product.

The whole system is used by more than 300 active users from all over the world for batch processing for their physics data analysis.

== [http://www.get2chip.com Get2Chip, Inc.] ==

"We are using XFS on 3 production file servers with approximately 1.5T of data. Quite impressive especially when we had a power outage and all three servers shutdown. All servers came back up in minutes with no problems! We are looking at creating two more servers that would manage 2+ TB of data store."

== [http://www.lando.co.za Lando International Group Technologies] ==

Lando International Group Technologies is the home of:

* [www.lando.co.za Lanndo Technologies Africa (Pty) Ltd] - Internet Service Provider
* [www.lbsd.net Linux Based Systems Design] (Article 21). Not-For-Profit company established to provide free Linux distributions and programs.
* Cell Park South Africa (Pty) Ltd. RSA Pat Appln 2001/10406. Collecting parking fees by means of cell phone SMS or voice.
* Read Plus Education (Pty) Ltd. Software based reading skills training and testing for ages 4 to 100.
* Mobivan. Mobile office including Internet access, fax, copying, printing, telephone, collection and delivery services, legal services, pre-paid phone and electricity services, bill payment email, secretarial services, training facilities and management services.
* Lando International Marketing Agency. Direct marketing services, design and supply of promotional material, consulting, sourcing of capital and other funding.
* Illico. Software development and systems analysis on most platforms.

"Throughout these companies, we use the XFS filesystem with [http://idms.lbsd.net IDMS Linux] on high-end Intel servers, with an average of 100 GB storage each. XFS stores our customer and user data, including credit card details, mail, routing tables, etc.. We have not had one problem since the release of the first XFS patch."

== [http://www.fcb-wilkens.com Foote, Cone, & Belding] ==

"We are an advertisement company in Germany, and the use of the XFS filesystem is a story of success for us. In our Hamburg office, we have two file servers having a 420 Gig RAID in XFS format serving (almost) all our data to about 180 Macs and about 30 PCs using Samba and Netatalk. Some of the data is used in our offices in Frankfurt and Berlin, and in fact the Berlin office is just getting it's own 250 Gig fileserver (using XFS) right now."

"The general success with XFS has led us to switch over all our Linux servers to run on XFS as well (with the exception of two systems that are tied to tight specifications configuration wise). XFS, even the old 1.0 version, has happily taken on various abuse - broken SCSI controllers, broken RAID systems."

== [http://www.moving-picture.co.uk/ Moving Picture Company] ==

"We here at MPC use XFS/RedHat 7.2 on all of our graphics-workstations and file-servers. More info can be found in an [http://www.linuxuser.co.uk/articles/issue20/lu20-Linux_at_work-In_the_picture.pdf article] LinuxUser magazine did on us recently."

== [http://www.coremetrics.com/ Coremetrics, Inc.] ==

"We are currently using XFS for 25+ production web-servers, ~900GB Oracle db servers, with potentially 15+ more servers by mid 2003, with ~900GB+ databases. All XFS installed."

"Also, our dev environment, except for the Sun boxes which all are being migrated to X86 in the aforementioned server additions, plus the dev Sun boxes as well, are all x86 dual proc servers running Oracle, application servers, or web services as needed. All servers run XFS from images we've got on our SystemImager servers."

"All production back-end servers are connected via FC1 or FC2 to a SAN containing ~13TB of raw storage, which, will soon be converted from VxFS to XFS with the migration of Oracle to our x86 platforms."

== [http://evolt.org Evolt.org] ==

"evolt.org, a world community for web developers promoting the mutual free exchange of ideas, skills and experiences, has had a great deal of success using XFS. Our primary webserver which serves 100K hosts/month, primary Oracle database with ~25Gb of data, and free member hosting for 1000 users haven't had a minute of downtime since XFS has been installed. Performance has been spectacular and maintenance a breeze."

<font size="-1"> ''All testimonials on this page represent the views of the submitters, and references to other products and companies should not be construed as an endorsement by either the organizations profiled, or by SGI. All trademarks (r) their respective owners.'' </font>

Main Page

2010-10-03T07:10:08Z

Ckujau: capitalize RPM :) we could also set up a redirect page, if really needed....

{| width="100%"
|-
|style="vertical-align:top" |


<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#E2EAFF; align:right;">
== Information about XFS ==

* [[XFS FAQ]]
* [[XFS Status Updates]]
* [[XFS Papers and Documentation]]
* [[Linux Distributions shipping XFS]]
* [[XFS Rpm for RedHat|XFS RPMs for RedHat]]
* [[XFS Companies]]
* [http://oss.sgi.com/projects/xfs SGI XFS website]
* [http://en.wikipedia.org/wiki/XFS Wikipedia XFS page]

</div>


<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#fffff0; align:right; ">

== Professional XFS Consulting Services ==

[[Consulting Resources]]
</div>

| width="50%" style="vertical-align:top" |


<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#F8F8FF; align:right;">
== XFS Developer Resources ==

* [[XFS email list and archives]]
* [http://oss.sgi.com/bugzilla/buglist.cgi?product=XFS&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Bugzilla @ oss.sgi.com]
* [http://bugzilla.kernel.org/buglist.cgi?product=File+System&component=XFS&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Bugzilla @ kernel.org]
* [[Getting the latest source code]]
* [[Unfinished work]]
* [[Shrinking Support]]
* [[Ideas for XFS]]
</div>

{{#meta: | u+4/+rib+YG96TifD0SN88xS84YSDm2cl61IU7ZIk9g= | verify-v1 }}

|}

User:Ckujau

2010-08-25T20:43:11Z

Ckujau: email address corrected

[mailto:xfswiki@nerdbynature.de Christian Kujau]

User:Ckujau

2010-08-25T20:42:36Z

Ckujau: New page: [mailto:lists___nospam@nerdbynature.de Christian Kujau]

[mailto:lists___nospam@nerdbynature.de Christian Kujau]