Theodore Tso wrote:

Also, looking more closely on the jbd2 implementation, it looks like
using the async_commit option, which relies on the checksum for more
efficient commit, completely disables any barrier support.  That's
because the only place we go into ordered more is if we are writing a
synchronous journal commit.  If async journal commit is enabled, then
we don't write a barrier at all, which leaves us in potential trouble
with if data blocks end up getting reordered with respect to the
journal commit in data=ordered more.

That is a great optimisation to make the filesystem safe against power
fails without barriers.  Upon replay, the filesystem is consistent.

But does it break fsync()?  Consistency isn't enough for fsync().
Returning from fsync() means "this data is committed now".

-- Jamie