Re: [RFC] ext4: orphan tracking after a failed truncate

["Theodore Tso" <tytso@mit.edu>]

On Tue, Aug 18, 2026 at 12:41:57PM -0500, Zhang Yi wrote:
> I think we might want to add a small qualifier here: this is only expected
> behavior under errors=continue. For the remount-ro case, we immediately
> abort the journal to prevent writing out inconsistent metadata after an I/O
> error, which helps contain the damage. So after journal replay, the file
> system should still be able to maintain a consistent state.

Errors={continue,remount-ro,panic} only apply if the ext4_error()
family is called.  The problem is that ext4_ext_remove_space(), which
is called by ext4_ext_truncate() calls read_extent_tree_block() and if
it returns an error, it returns EIO without actually calling
ext4_error().  So the truncate system call will return EIO, with
i_size set to zero, but with blocks beyond EOF still left allocated.

As I menstioned, that's not _fatal_ in that case, since blocks beyond
EOF can happen with fallocate(2) with FALLOC_FL_KEEP_SIZE.  But it
could be a bit surprising, since truncate return an error, but the
file was actually apparently truncated (or partially truncated, in any
case).

We could change it to call ext4_error() which would signal the system
administrator would get a clear signal that she should run fsck, but
in terms of bugs, it's not as serious as if the file system was left
actually corrupted.

Cheers,

					- Ted