|This is the talk page for discussing improvements to the XFS article.|
|WikiProject Computing / Software||(Rated C-class, Low-importance)|
- 1 Introduction
- 2 Infobox
- 3 History
- 4 Specifications: Journaling
- 5 Disadvantages
- 5.1 Access from Windows
- 5.2 32/64-bit environments
- 5.3 Relevance of disadvantages
- 5.4 Ubuntu 6.10
- 5.5 Deleted file recovery
- 5.6 Powerfail Corruption Disadvantage
- 5.7 Simple (but noticeable) grammar error
- 5.8 Possible disadvantage: Lilo
- 5.9 Removed "error checking could be improved" disadvantage
- 5.10 Incoherent desciption of the 32bit inode limit
- 6 New features: Lazy Superblock Counters and Concurrent Multi-File Data Streams
- 7 Guaranteed-rate I/O and Linux
- Well, it stands for 'X File System', where X=$VALUE, of course! But I assume that the X may be a character selected with little significance. Freedomlinux 04:22, 4 March 2007 (UTC)
- I've just chanced upon the following:
- “The original XFS design was circulated within SGI in October 1993 as ‘xFS: the extension of EFS’. … ‘x’ for to-be-determined (but the name stuck)” —XFS ondisk format, http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf, accessed 2007-12-09.
- I.e. (as I understand it) ‘X’ didn't stand for a word, it was just a placeholder until a name was chosen. If there's anything to my “vague recollection”, then it would have been a post-hoc justification for the ‘X’.
- I haven't updated the article to include this.
- Pjrm (talk) 22:05, 9 December 2007 (UTC)
Very poor content
"XFS is particularly proficient at handling large files and at offering smooth data transfers."
Since this is the intro to the article, unexplained, and unsourced, I'm changing this with factual information contained later in the article, which also is what sets XFS apart from most, if not all, contemporary filesystems, which is internal parallelism. Hardwarefreak (talk) 00:45, 28 November 2011 (UTC)
It's not very unexplained - XFS was, in its earlier incarnations, designed by SGI for handling what were then very large files, often streaming data to devices that dealt poorly with buffer underrun type issues. The guaranteed rate IO was all about providing smooth transfers or large files, and was mostly about the ability to stream reads or writes on arbitrarily large files. The parallelism was there as an implementation route to meeting those design aims. Hard guarantees on ratio IO are largely academic today, as XFS is no longer mostly found on Irix systems with hardware support for these features in the storage layers. The original sentence provided a better view of the rationale involved in XFS design than the current wording, though this should perhaps be extended now to point out that the use case for XFS on Linux today is not quite the same as the common workloads encountered on Irix systems in the early 1990s. — Preceding unsigned comment added by 220.127.116.11 (talk) 02:16, 24 November 2013 (UTC)
Max file size and Max volume size
Shouldn't this be listed as ~8.5EB (9 million TB) and ~17EB (18 million TB) respectively?
--RageX 05:16, 5 January 2007 (UTC)
Max File and volume size
With ProPack for Linux, the size is 16EB max filesystem and 8EB max file. Since this represents limitations of the underlying OS and not the FS, these vales should be (and were) adjusted accordingly. see http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=bks&srch=&fname=/SGI_Admin/LX_XFS_AG/sgi_html/ch01.html
OpenBSD does not support XFS
FreeBSD has _experimental_ support, OpenBSD has not at all.
18.104.22.168 00:48, 21 September 2007 (UTC)
Earlier I wrote: "I see no Fedora entry yet in History, or anywhere else on the XFS page. Whilst it is not strictly true that Fedora (I am using F7 test 3) "offer[s] XFS as a choice of filesystem" it is not hard to turn it on, and it does offer read/write ability. I read that if you boot from a CD, you can type "linux xfs" and you will then find xfs as one of the format choices in the partition druid. I network load using pxelinux, so what I did was to add xfs to the file under pxelinux.cfg directory:
kernel vmlinuz append xfs initrd=initrd.img
and was pleased to find xfs was then a choice once I reached the druid.
Would the XFS guru please consider mentioning Fedora therefore?
My interest is that sometime I would like to set up a MythTV/Fedora machine, and I read that XFS is a much better file system (than ext3) for video content. RegardsNickSharp 23:52, 5 April 2007 (UTC)"
Following no response, I have added a small section at the end of "History". NickSharp 21:29, 17 April 2007 (UTC)
XFS is the oldest journaling file system available ...
How does that statement relate to JFS on AIX 3.1? I had an account on such a box in 1992 though I can't tell when it was released. —Preceding unsigned comment added by 22.214.171.124 (talk) 06:01, August 29, 2007 (UTC)
- The JFS (file system) page claims that JFS was released in 1990, so I've weakened the claim on this page to "among the oldest".
- Pjrm (talk) 07:55, 8 December 2007 (UTC)
XFS support in Red Hat Enterprise linux 5u4
XFS will be supported in RHEL 5u4 : http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html-single/Release_Notes/.
126.96.36.199. Filesystems [...] Support for the XFS file system has also been added to the kernel (BZ#470845). —Preceding unsigned comment added by 188.8.131.52 (talk) 17:20, 2 August 2009 (UTC)
This page used to claim that XFS provides “guaranteed file system consistency”. This claim is unclear: pretty much every filesystem remains consistent in normal operation, and no filesystem (including XFS) guarantees filesystem consistency in the face of corruption of the underlying bits (media failure or someone misusing dd or operating system failure), and I'm not aware of any formal proof that XFS guarantees filesystem consistency (and in any case it will depend on what guarantees the storage device provides (about reordering etc.).
I've changed the relevant text to say that “journaling is an approach to guaranteeing ...” and “allows XFS to retain consistency” (instead of “to guarantee consistency”).
The word "partitioning" is used here to describe the internal filesystem on disk structure. The word is being used in its generic dictiontary form--divide into multiple sections. This has nothing to do with "disk partitioning". Someone linked the word "partitioning" to the disk partitioning article. Apparently the editor who did this has no knowledge or understanding of XFS allogation groups. The existence of that link simply serves to spread misinformation, giving the reader a complete misunderstanding of allocation groups. Thus I am removing link. Hardwarefreak (talk) 15:46, 28 November 2011 (UTC)
Access from Windows
Is there a utility that can read from XFS partitions under Windows? If not, that could be listed in the Disadvantages section, since ext2/3 can be read and written from Windows. AxelBoldt 00:33, 30 May 2006 (UTC)
- Currently not, as far as I'm aware, but then that's true for most Unix filesystems, and I'm not sure compatibility with random foreign operating systems should really be listed as a disadvantage. The article could also do with a little further extension, as XFS provides support for extended attributes/forks, which hasn't yet been added 184.108.40.206 23:06, 30 May 2006 (UTC)
- (See also Relevance of Disadvantages, below.)
Under disadvantages, it says that XFS can't be read from windows. [crossmeta.com Crossmeta] seems to think otherwise, anyone with more knowledge want to offer an opinion?
- Crossmeta implements an older disk format of XFS that is not practical. In addition, users tend to report that Crossmeta's product is unstable and dangerous. 220.127.116.11 00:32, 5 December 2006 (UTC)
- That's a disadvantage of Windows, not XFS. — Chameleon 00:38, 23 October 2008 (UTC)
I am running a 64 bit linux project/distro using xfs and can run 32 bit compiled applications, could someone explain what that means that 32 and 64 bit enviroments do not work? as i am running 64 and 32 bit applications on xfs on the same machine. thank you—The preceding unsigned comment was added by Allix (talk • contribs) 2006-07-17T19:12:21.
The discussed "compatibility issue" between 32-bit and 64-bit modes is a possible filesystem corruption scenario when using the same XFS filesystem on 32-bit and 64-bit Linux (i.e. dual boot, external hard drive, etc) . If you try to mount in 64-bit mode a dirty XFS volume last used in 32-bit mode (or vice versa), the attempt to replay the journal will result in a corrupted/damaged filesystem (xfs_repair is your best friend then). i've heard, however, in #xfs that this has been fixed in 2.6.18. I cannot confirm that.—The preceding unsigned comment was added by 18.104.22.168 (talk • contribs) 2006-10-16T21:34:52.
This entire topic can be easily resolved, when the journal is cleared before mounting the fs on another platform. I say platform, because due to architectural differences the same problem applies also to x86 -> ppc, etc. XFS journals are very optimized and due to that don't contain informations about endianess, datatype-size, etc., and must be cleaned before mouting on another environment. Unfortunately XFS doesn't do this by itself. --22.214.171.124 10:14, 26 October 2007 (UTC)
Relevance of disadvantages
There are a lot of things landing under the disadvantages section that really don't belong there. People have put in notes about Linux distribution implementation details, installer support, windows access and other stuff that, while they may be interesting are not disadvantages of the XFS filesystem. They're simply side issues that people may face. Maybe they should be moved into another section?
126.96.36.199 13:00, 6 December 2006 (UTC)
- If using filesystem Y allows accessing the filesystem from MS Windows while using XFS does not, and if it is useful to access the filesystem from MS Windows (removable media or dual-boot PC), then in practical terms this is a disadvantage of XFS compared to filesystem Y. Granted, the problem is not inherent in the format —nothing prevents one from writing software to access the data from other operating systems except that it requires many hours of work from a knowledgable programmer— but it is nevertheless a practical disadvantage and relevant to many people interested in what the disadvantages of XFS are.
- Pjrm (talk) 05:39, 8 December 2007 (UTC)
The article says ubuntu does not allow to use XFS in the root partition ? Untrue!
I have partitioned my root directory in ubuntu 6.10 with xfs and everything works fine and snappy. What's true is that it chose lilo instead grub as the bootloader. But in ubuntu it works now , maybe in the previous releases that was not the case. —The preceding unsigned comment was added by 188.8.131.52 (talk) 20:56, 6 December 2006 (UTC).
Moreover, I removed lilo and installed grub, and Ubuntu 6.10 can boot just fine from an XFS partition. I'm removing that comment from the article. 184.108.40.206
Deleted file recovery
Under disadvantages, the article states that recovery of deleted files from an XFS partition is particularly difficult. Can anyone provide sources for this statement or explain it? -220.127.116.11 16:53, 11 April 2007 (UTC)
- I remove that bit because there is no evidence that XFS is any more difficult to recover files from than any other file system that lacks an undelete utility. Also the rest of the disadvantage section was cleaned upLotu 22:56, 14 June 2007 (UTC)
- More than that, it's not the basic lack of utility, the main reason is how data is stored and handled: When unlinking is done, unlike in ext2 or fat there is no more trace for finding a link between a filesystem-entry and it's data-sections, therefor recovery is extremely hard (almost impossible) and would require some sort of log keeping track of the file locations. However, today there are lots of recycle-bin utils, even a fetcher for glibc, so I would use those instead ;-) --18.104.22.168 10:18, 26 October 2007 (UTC)
Powerfail Corruption Disadvantage
About the item under disadvantages that says "XFS journals metadata but not data, so during a sudden loss of power, data can be corrupted.SGI (August 28, 2006)." - reading the cited source, it appears that this is only a problem if the disk has write cache enabled and the cache hardware isn't reporting when the write is physically completed. This in not specific to XFS, but can occur with any file system if the hardware is in that configuration. The citation also provides some mitigations, including using hardware with persistent cache to preserve the data in the cache during a power fail, and also using barrier support to force-flush the cache. I don't think this belongs as a disadvantage for XFS. As a matter of fact, given that there is a mitigation built into the filesystem, I believe that this is an advantage. The disadvantage should be removed.
Eric Paynter 02:23, 6 July 2007 (UTC)
I now have the ability to edit this page, so I removed this disadvantage.
Eric Paynter 03:14, 13 July 2007 (UTC)
- I understand that the problem (or a problem, at any rate) arises when metadata and file updates are not ordered. That is, for example, you append new data to a file, and the file growth (which is a metadata update and therefore journaled) takes place, but the new data is never written to disk.
- If writes were ordered, the new data would get flushed before the accompanying metadata update; that way, the end of the file wouldn't contain garbage/zeroes after the journal is replayed.
- XFS does seem to have this problem (at least my personal experience suggests so), whereas e.g. ext3 doesn't (if journal=ordered).
- --22.214.171.124 23:03, 8 October 2007 (UTC)
Simple (but noticeable) grammar error
In the "Disadvantages" section, the (5th as of this writing) item says "...disk when is is received, so..." - I'm pretty sure the author of that section wanted "it is" so someone with access to the page might want to fix that.
Dav7 12:53, 12 July 2007 (UTC)
- Thanks, fixed.-gadfium 20:38, 12 July 2007 (UTC)
Possible disadvantage: Lilo
It should be mentioned that if you want to use Lilo and XFS, you need separate non-xfs partition for Lilo:
/boot (for example ext3, reiserfs, jfs)
because "XFS superblock is written at block zero, where LILO would be installed" (see quote). Also it is possible to install Lilo in MBR and use / (xfs) without separate /boot partition.
"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."
126.96.36.199 18:53, 20 September 2007 (UTC)
- I wouldn't see this as disadvantage, since partition-based bootblocks have their own serious disadvantages (that's why almost all modern boot managers - for example grub and ntfsldr, doesn't do it that way, and only provide MBR-based booting by default) --188.8.131.52 10:20, 26 October 2007 (UTC)
Removed "error checking could be improved" disadvantage
This disadvantage referenced a paper at wisc.edu. Once it was published, an XFS developer quickly addressed all shortcomings. So, I've removed this item. —Preceding unsigned comment added by 184.108.40.206 (talk) 19:51, 19 January 2010 (UTC)
Incoherent desciption of the 32bit inode limit
If you have a file system that's close to 1 TB and it gets full, when you grow the file system size, you might get a "no space left" later on error anyway. XFS by default uses 32 bit inodes that are to be located within the first TB of data. In order to use the new space added after the first TB you need to either : a) move data out of and back in to the file system, so that when the file system is repopulated, it starts using space over the first TB and be able to devote more space in the first TB for inodes or b) use the inode64 mount option on the file system mount table to allow for 64-bit inodes to work so they can live in any place of the file system. 64-bit inodes can be an issue with certain backup software.
is not even close to encyclopdia quality content. It's so poorly written I have trouble deciphering it. I think I know the situation the author is referring to, but he has not come close to properly describing it. Additionally, this is not a "disadvantage" of XFS. It is a known design point and there is substantial documentation that teaches users how to properly grow the filesystem in this situation. Thus I'm removing this entirely. Hardwarefreak (talk) 16:02, 28 November 2011 (UTC)
New features: Lazy Superblock Counters and Concurrent Multi-File Data Streams
Lazy Superblock Counters: When there are a couple of hundred transactions on the fly at once, they all typically modify the on disk superblock in some way. , locking the buffer until the transaction is committed into the incore log buffer. The result of this is that with enough transactions on the fly the incore superblock buffer becomes a bottleneck. In 2.6.23, XFS avoids this bottleneck (see commit for details). But due the way XFS works, in order to make it work well with this new feature, a new counter was added to track the number of blocks used by the free space btrees. This is an on-disk format change. As a result of this, lazy superblock counters are a mkfs option and at the moment on linux there is no way to convert an old filesystem, although one solution will be developed. Code (commit)
Concurrent Multi-File Data Streams: In media spaces, video is often stored in a frame-per-file format. When dealing with uncompressed realtime HD video streams in this format, it is crucial that files do not get fragmented and that multiple files a placed contiguously on disk. When multiple streams are being ingested and played out at the same time, it is critical that the filesystem does not cross the streams and interleave them together as this creates seek and readahead cache miss latency and prevents both ingest and playout from meeting frame rate targets. This feature creates a "stream of files" concept into the allocator to place all the data from a single stream contiguously on disk so that RAID array readahead can be used effectively. Each additional stream gets placed in different allocation groups within the filesystem, thereby ensuring that XFS doesn't cross any streams. Code: (commit)
220.127.116.11 19:19, 20 September 2007 (UTC)
Guaranteed-rate I/O and Linux
What about the Garantied-rate I/O on Linux Novel SLES or Red Hat Enterprise? This article suggests that every XFS implementation provides this garantied I/O features. I have heard that this is not true. Who knows more? What about special hardware needs for this feature? Should this be corrected in this article?