Slashdot Mirror

← Back to Stories (view on slashdot.org)

Anatomy of Linux Journaling File Systems

Posted by timothy on from the dear-diary dept.

LinucksGirl writes "Journaling file systems used to be an oddity primarily for research purposes, but today it's the default in Linux. Discover the ideas behind journaling file systems, and learn how they provide better integrity in the face of a power failure or system crash. Learn about the various journaling file systems in use today, and peek into the next generation of journaling file systems."

11 of 59 comments (clear)

  1. Obligatory. by Tackhead · · Score: 4, Funny

    "And then there's ReiserFS, which had integrity issues when it came to retrieving the location of a bunch of widely-scattered bits under an unbalanced tree."

    1. Re:Obligatory. by nawcom · · Score: 4, Insightful

      when it came to retrieving the location of a bunch of widely-scattered bits... go ahead, mod me down, but for a second there i thought there was some inside joke referring to his wife in Tackhead's post.
    2. Re:Obligatory. by Anonymous Coward · · Score: 4, Funny

      Replace "widely-scattered bits under and unbalanced tree" with "dead wives," and then I think you've got it.

      If you had done so automatically and silently as intended, then I think you'd have gotten "the joke".

    3. Re:Obligatory. by MSG · · Score: 4, Funny

      Jokes about murder aren't funny. What's wrong with you?

    4. Re:Obligatory. by LingNoi · · Score: 4, Funny

      I saw this post on the main page and instantly knew they'd be a Reiser joke. In fact, that's all I came here for, cya!

    5. Re:Obligatory. by drinkypoo · · Score: 5, Insightful

      I've been in car crashes, yet jokes about car crashes are still funny in spite of my personal experience to tell me that the event itself is potentially very serious. I only hope that if someone I care about is murdered, I'll still manage to retain my sense of humor. It would be a shame if it had to die, too.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  2. File systems should know more about file type by Animats · · Score: 5, Interesting

    File systems should know more about file type. Not "file type" in the extension sense, but file type in the sense of what the data written to the file needs for integrity.

    There are only a few standard use cases:

    • The entire file is the commit unit. For most files, you either want the entire file written correctly or you don't want anything written. When nothing is written, the previous version, if any, should remain intact. Applications with "Save" functions need this model. For many binary file types, from images to executables, a partial file is totally useless. So the file should be committed when closed. IBM put this in some of their early UNIX versions, the ones based on UCLA Locus. Done right, if the program crashes before closing or committing the file, the file reverts to the old version. It's not necessary to update the metadata until file close, so this is the fastest mode, and should be the default.
    • Log files. Files are only extended; old data is not overwritten. Ordered journaling is desirable, so that after a crash, the file is intact out to the point of the crash. This is UNIX "open for append" mode.
    • Database files. The file is being used to support a database with read/write data structures. The database system needs to know when the file system has committed a write and may need to know about ordering of queued writes. This is the most complex case, but database implementors pay attention to file system details and are willing to make special calls if necessary to tell the file system when to commit and to wait for commits to complete.

    If those three cases are properly supported, you should never see a garbled file from an unexpected shutdown. Some of the file systems out there have approximately the right feature set for this, but there's no standardized interface and set of expectations that corresponds to these use cases.

    1. Re:File systems should know more about file type by klapaucjusz · · Score: 4, Interesting

      The entire file is the commit unit. For most files, you either want the entire file written correctly or you don't want anything written. When nothing is written, the previous version, if any, should remain intact.

      You don't need any extra kernel support for that. You just write the new version under a temporary name, and then atomically rename it over the old file. Fsync before renaming for extra credit.

      Good text editors have been doing that for as long anyone can remember.

      Log files. Files are only extended [...] This is UNIX "open for append" mode.

      Unfortunately, it doesn't work very well, since POSIX doesn't (AFAIK) specify the largest write that is guaranteed to be atomic. Hence, unless you're careful, you may end up with log entries from two processes being interleaved.

    2. Re:File systems should know more about file type by Carnildo · · Score: 5, Informative

      MacOS is probably the most advanced in this regard: it's got a system call for "swap the contents of these two files". This does an atomic swap, and as a side benefit, preserves any links to the files.

      --
      "They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
  3. I am jack's file system by Anonymous Coward · · Score: 5, Funny

    Dear journal,

    Today I was suddenly restarted. It seems as if the large meat machine which regularly uses me was startled by a file which was being written to my logs, "goatse.jpg". Fortunately, thanks to my reliability, The meat machine will be able to view the image upon his return! I hope it is happy with me!

    Yours truly,
    XFS

  4. More interesting story: by bersl2 · · Score: 5, Informative

    Barriers and journaling filesystems