Slashdot Mirror

← Back to Stories (view on slashdot.org)

SGI open-sourcing XFS

Posted by ryuzaki0 on from the it's-sorta-tomorrow dept.

Yun Ye writes "Finally, a journaling FS for Linux! Get the full story . Excellent-we'll have to ask the SGI people about it tomorrow. And who came up with the name change. Whatever the case, this will help Linux continue to crack the high-end market.

4 of 179 comments (clear)

  1. more than three by Anonymous Coward · · Score: 5

    For real high-end stuff:

    1. Poor large memory support. I'm not sure how the most recent kernels fare, but last I checked Linux only supports a maximum of 2GB of ram. This is probably one of the FIRST things which need to be fixed. I have heard that SGI is working on a patch to give 3.8GB on Intel machines... that sounds promising!

    2. No raw I/O support. This is used for large RDBMS's for example. AFAIK Linus hates the idea, so it will probably never get this. Mind you this is minor because there are ways around it.

    3. "fsync()" on large files is extremely inefficient. Again, this affects RDBMS to the extreme. It is so bad that in some cases Windows NT is 30 or 40 times faster than Linux on equivalent hardware doing database inserts and updates. To witness this for yourself, write a quick program that opens a file and loops appending a line and doing an fsynch on it. Notice the slowdown as the file grows. That shouldn't happen.

    4. Poor performance under load. When the load on a Linux box goes up, context switch time increases a LOT. This is bad.

    And these are just off the top of my head...

    Mind you, I am not diminishing Linux, it is still my primary development platform of choice, however as it stands it doesn't make a good platform for really big single-computer tasks. I'm sure this will change in the future, but right now as much as I hate to say it, NT and commercial Unix have the lead. Also I'd love to hear corrections to my points above, they would be good news to tired eyes.

    Thanks

  2. SGI listens to users by Thunderbear · · Score: 4

    Some time ago Silicon Graphics asked for comments from users regarding what we wanted, and I replied that opensourcing xfs was probably the most relevant thing they could do. Since apparently SGI is moving away from their Irix95, and they have a huge investment in xfs development, this appears to be a natural step towards having xfs on their Linux platform. This is really a good thing, and the only OpenSource initiative SGI has done so far which will actually matter to most users. Now 4dwm would be nice too - that is really a nice window manager.

    --

    --
    Thorbjørn Ravn Andersen "...and...Tubular Bells!"
  3. Re:what is the difference? by cpeikert · · Score: 4

    There have been a few good answers to this question in this thread, but there's one thing that hasn't been pointed out yet: journaling file systems don't (immediately) overwrite a file when it is changed.

    To elaborate, imagine a long tape that represents your hard drive. The tape is written from left to right. When a file is changed, the new version is appended to the end of the existing data, while the old version remains "untouched" farther to the left. When the kernel has finished updating all pending file writes, it can write a "checkpoint" at the end of the existing data. Essentially the checkpoint says "everything up to the point is kosher." If the disk gets really full, then the filesystem can double-back and overwrite the really old data at the beginning of the tape.

    Now, let's see how this works to help recover from crashes; say the computer crashes as it's writing out a file to disk. In a conventional filesystem, a lot of things could go wrong: it could have been overwriting the old data, but finished only half of the job. Then, at best, you've got a corrupted file with a hybrid of new data and old data. The file allocation table may not have been updated, so the file may be completely lost. It's a bad situation.

    Conversely, if the crash happened with a JFS, the computer would run an "fsck" and look for the last checkpoint. It's guaranteed that all data preceding the checkpoint has integrity. Then the filesystem would just work from that checkpoint and ignore any non-checkpointed data. This can still lead to some data loss, but never to filesystem corruption.

    Of course, this is a simplified account, and there are implementation details. But that's the gist of it.

  4. Splendid! by kris · · Score: 5

    If the license for XFS is any sensible (i.e. a true Open Source license), this is the single most intelligent thing SGI could have done to score with the Open Source movement. Linux is in dire need of an Journalling File System and XFS is one of the very best of this flock.

    Their white paper on XFS explains how XFS is different from conventional file systems and what they did to it to make it fast with very large files as well as with many, many small files (SGI is not Open Sourcing their GRIO capabilities, which together with RT scheduling would make Linux a serious multimedia contender).

    If you are a USENIX member, you will be able to download the Sweeney paper Scalabilit y in the XFS File System from the USENIX server. It was published in the Spring 1996 proceedings of the USENIX, so you may also read it in your Universities library.