[ ... ]
>>> write barriers will ensure journal and thus filesystem
>>> integrity in a crash/power fail event. They do NOT guarantee
>>> file data integrity as file data isn't journaled.
Not well expressed, as XFS barriers do ensure file data integrity,
*if the applications uses them* (and uses them in exactly the
The difference between metadata and data with XFS is that XFS
itself will use barriers on metadata at the right times, because
that's data to XFS, but it won't use barriers on data, leaving
that entirely to the application.
>>> No filesystem (Linux anyway) journals data, only metadata.
>> That's not true, is it? ext3 and ext4 support journal=data.
They do, because they journal blocks, which is not generally a
great choice, but gives the option to journal data blocks too more
easily than other choices. But it is a very special case that few
Also, there are significant issues with 'ext3' and 'fsync' and
«There is one other important change needed to get a truly
quick fsync() with ext3, though: the filesystem must be
mounted in data=writeback mode. This mode eliminates the
requirement that data blocks be flushed to disk ahead of
metadata; in data=ordered mode, instead, the amount of data to
be written guarantees that fsync() will always be slower.
Switching to data=writeback eliminates those writes, but, in
the process, it also turns off the feature which made ext3
seem more robust than ext4.»
On a more general note, journaling and barriers are sort of
The real purpose of barriers is to ensure that updates are
actually on the recording medium, whether in the journal or
directly on final destination.
That is barriers are used to ensure that data or metadata on the
persistent layer is current.
The purpose of a journal is not to ensure that the state on the
persistent layer are *current*, but rather *consistent* (at a
lower cost than synchronous updates), without having to be
careful about the order in which the updates are made current.
The updates are made consistent by writing them to the log as
they are needed (not necessarily immediately), and then on
recovery the order gets sorted out spatially.
Currency does not imply consistency (if the updates are made
current in some arbitrary order) and consistency does not imply
currency (if the recording medium is kept consistent but updates
are applied to it infrequently).
The BSD FFS does not need a journal because it is designed to be
very careful as to the order in which updates are made current,
and log file systems don't aim for spatial currency.
> And btrfs supports COW (as does nilfs2) with "transactions",
> which should/could be similar?
Not quite. They are more like "checkpoints", that is alternate
root inodes that "snapshot" the state of the whole filetree at
These are not entirely inexpensive, and as a result as I learned
from a talk about some recent updates about the BSD FFS:
COW filesystems like ZFS/BTRFS/... need to have a journal too to
support 'fsync' in between checkpoints.
BTW there are now COW versions of 'ext3' and 'ext4', with
The 'freeze' features of XFS does not rely on snapshotting, it
relies on suspending all processes that are writing to the
filetree, so updates are avoided for the duration.
As the XFS team have been adding or planning to add various "new"
features like checksums, maybe one day they will add COW to XFS
too (not such an easy task when considering how large XFS extents
can be, but the hole punching code can help there).