Anatomy of Linux Journaling File Systems

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

Comments

File systems should know more about file type

[Animats]

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.

Re:File systems should know more about file type

[Carnildo]

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.

I am jack's file system

[Anonymous Coward]

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

More interesting story:

[bersl2]

Barriers and journaling filesystems

Re:Obligatory.

[drinkypoo]

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.