Atomic file system

I had a discussion with a delegate about pros and cons of a journalling file systems. What is special about them, and what are their main characteristics - in other words, is it worth to upgrade to a journalling file system from a traditional predecessor.

First of all, why would anybody be still working with a filesystem that is *not* journalling. Long gone the days where administrator would be prepared to do a full system fsck, just in case there is a filesystem inconsistency.

The main characteristic of a journalling filesystem is the fact that it can maintain a log of all transactions. However, unlike "standard" system logs, which record transactions after the event, filesystem logging records intentions, before the operation is even attempted (although there are various methods of achieving this, and some - such as metadata-only journalling - are more efficient than others). Of course, there is penalty in logging: in both performance and disk space, so for that reason, some administrators switch the logging off. How crazy! This is the very feature that journalling filesystems excel at, yet for many admins the term journal, or log seems to be sufficiently off-putting to turn it off!

Therefore, when describing a journalling filesystem for the first time to, I tend to use another term as the main characteristic: I introduce these filesystems as "atomic filesystems", rather than journalling. Atomic transaction means it either happens fully, completely and successfully, or it doesn't happen at all. One can provide numerous illustrations why data transfers, file and directory manipulation or database transactions should have the atomic nature.

But the moral of the story is: once you turn the attention to the advantages of transaction atomicity, then the term journal is not that scary anymore...