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

On 8/18/2026 9:48 PM, Theodore Tso wrote:
> 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.
> 

I checked the code. Apart from the verity path, all callers
of ext4_truncate() already call ext4_handle_error() when it returns
an error. So it doesn't look like there's any issue with truncate
at the moment. So I suspect that Guanghui won't be able to reproduce
this issue in remount-ro mode, and I'd suggest that similar consistency
tests under fault injection scenarios should all be run in remount-ro
mode.

> 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).
> 

It seems we can't guarantee that the file being truncated is always
preallocated. If the blocks were already in written state, then after
we update i_disksize to 0 but there are still blocks left unreleased,
fsck will still complain, Did I get this right?

Best Regards
Yi.

> 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
>