Talk:XFS

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the XFS article.

Article policies

Contents

[edit] Introduction

[edit] 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)

[edit] Infobox

[edit] 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)

[edit] 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)

[edit] OpenBSD does not support XFS

FreeBSD has _experimental_ support, OpenBSD has not at all.

85.222.21.198 00:48, 21 September 2007 (UTC)

Fixed. -- intgr [talk] 09:27, 21 September 2007 (UTC)

[edit] History

[edit] 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)

[edit] 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)

[edit] Specifications: Journaling

[edit] 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)

[edit] Disadvantages

[edit] 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)


[edit] 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 (talkcontribs) 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)

[edit] 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)

[edit] 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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)


[edit] 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)