From reading the docs it would seem like since new data is written to the journal it is no longer updated in place, technically achieving the same "atomicity" a CoW filesystem would provide.

So is there anything that makes a CoW filesystem "more atomic" than ext4 with data=journal?

Are there theoretical or proven cases where one would/does provide more crash safety than the other?

Or maybe CoW could be seen as an "implementation detail" which provides better performance? Seeing as data=journal is not the default due performance concerns.

  • Read some more - this is far too complicated to answer here. There is a huge gap between theory and practice - no two projects have the same number of issues. Disk manufacturers aren't always honest about their products capabilities.
    – symcbean
    Commented Sep 16, 2021 at 19:30

1 Answer 1


Running with data=journal isn't the same as COW, because it writes all of the data twice each time - once into the journal, does a transaction commit, then checkpointed to the filesystem and freed from the journal. A COW filesystem allocates new blocks for each write, writes into those new blocks, does a transaction commit, then (eventually) frees the old blocks (modulo snapshots).

There was an ext4 patch series developed for SMR drives that essentially made data=journal into a log-structured filesystem mode, where the journal was very large and did not pin the metadata and data pages in RAM. The blocks in the journal could potentially live there a long time without ever being checkpointed to the filesystem, until the filesystem was getting "full" from the journal, and the journal had to checkpoint the old transactions. That would either result in the blocks finally being written into the filesystem, or re-journaled to a new transaction.

This SMR patch series is available at:


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .