Talk:XFS/Archive 1

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

New features: Lazy Superblock Counters and Concurrent Multi-File Data Streams

http://kernelnewbies.org/Linux_2_6_23#head-00a396149d15f77d386939dc88f5be0f7e5b748a

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)

85.222.21.198 19:19, 20 September 2007 (UTC)

Infobox

Max file size and Max volume size

Shouldn't this be listed as ~8.5EB (9 million TB) and ~17EB (18 million TB) respectively?

See:

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

24.3.148.90 (talk) 09:14, 10 January 2008 (UTC)

OpenBSD does not support XFS

FreeBSD has _experimental_ support, OpenBSD has none at all.

85.222.21.198 00:48, 21 September 2007 (UTC)

Fixed. -- intgr [talk] 09:27, 21 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?

--Hummy2 (talk) 22:19, 11 January 2011 (UTC)

History

Fedora?

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 155.56.68.221 (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/.

IT is available in a different RHN channel, at extra cost. —Preceding unsigned comment added by 188.174.100.128 (talk) 23:58, 13 February 2011 (UTC)

1.4.1.3. Filesystems
[...] Support for the XFS file system has also been added to the kernel (BZ#470845).  —Preceding unsigned comment added by 82.224.164.22 (talk) 17:20, 2 August 2009 (UTC)

Specifications: Journaling

Guaranteed consistency

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”).

Pjrm (talk) 08:18, 8 December 2007 (UTC)

Allocation Groups

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)

Disadvantages

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 80.177.68.178 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. 24.192.234.18 00:32, 5 December 2006 (UTC)

That's a disadvantage of Windows, not XFS. — Chameleon 00:38, 23 October 2008 (UTC)

32/64-bit environments

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 24.192.138.190 (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. --87.139.20.72 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?

85.133.1.2 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)

Ubuntu 6.10

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 87.69.217.174 (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. 87.244.137.122

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? -84.172.236.187 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 ;-) --87.139.20.72 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).

--195.56.53.118 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)

/ (xfs)

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.

Quote from http://oss.sgi.com/projects/xfs/faq.html#lilowork

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

85.222.21.198 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) --87.139.20.72 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 64.131.60.146 (talk) 19:51, 19 January 2010 (UTC)

Incoherent desciption of the 32bit inode limit

This:

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)

Introduction

XFS?

perhaps tell what XFS stands for? _→AzaToth 18:22, 3 December 2006 (UTC)

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 vaguely recall that it stands for something like ‘extensible’, with reference to its provisions for high capacity and/or its support of extended attributes. Just a vague recollection, I haven't tried to verify it.

Pjrm (talk) 08:09, 8 December 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."

This unsourced sentence is also unexplained. What exactly does smooth mean and how large is large? --213.130.252.119 (talk) 03:56, 2 May 2010 (UTC)

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 81.187.150.195 (talk) 02:16, 24 November 2013 (UTC)

Historical user complaints

I renamed the "Comparison" section to the above. Prior to that it was named "Disadvantages". I removed the entry with the link to the Phoronix benchmark article because it is not relevant to this section, and simply not relevant to the XFS article. The reference to EXT4 WRT Delayed Logging is to demonstrate the relative improvement of XFS metadata performance, as EXT3/4 always had the fastest single threaded metadata performance. It does not make a claim that XFS is "faster" or "slower" than EXT4, but simply establishes context. It is not appropriate to "rebut" this as was done with the Phoronix addition. And in fact adding such benchmark references to any of the filesystem articles is not appropriate, especially given than the various filesystems leapfrog one another WRT performance over time, due to kernel bugs, etc. Hardwarefreak (talk) 16:05, 5 August 2014 (UTC)

Hello there! To me, "Disadvantages" is a much better section title, as "Historical user complaints" title would suit better to a subsection of the XFS § History section, while the content simply doesn't fit there. Hope you agree. — Dsimic (talk | contribs) 06:46, 6 August 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on XFS. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

Added archive http://web.archive.org/web/20140209075717/http://www.ibm.com/developerworks/library/l-fs9/index.html to http://www.ibm.com/developerworks/library/l-fs9/index.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

N An editor has determined that the edit contains an error somewhere. Please follow the instructions below and mark the |checked= to true

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 15:43, 27 February 2016 (UTC)