https://bugzilla.kernel.org/show_bug.cgi?id=207729 Jan Kara (jack@xxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |jack@xxxxxxx --- Comment #1 from Jan Kara (jack@xxxxxxx) --- Thanks for the report! So it is actually a description of data_err=abort mount option that is somewhat misleading. Let me explain a bit more: Ext4 in data=ordered mode guarantees to write contents of newly allocated data blocks during transaction commit, after which changes that make these blocks visible will become durable. In practice, whenever a new blocks are allocated for a file, we write out the range of a file that covers all the newly allocated blocks but that's just an implementation detail. And data_err=abort controls the behavior when this particular writeout of data blocks fail. In your test there are no newly allocated blocks in the transaction so the data_err=abort does not apply. To explain some rationale, such data writeback errors are indeed more serious because if we just committed the transaction despite these errors, the newly allocated blocks could expose stale, potentially security sensitive, data from other files. So that's why the option was introduced. But I agree that the documentation is misleading and the semantics of the option is somewhat peculiar. I'll talk to other ext4 developers how we could possibly improve the situation. -- You are receiving this mail because: You are watching the assignee of the bug.
