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

On 8/17/2026 11:56 PM, Jan Kara wrote:
> Hi!
> 
> Quick note for Ted: these kind of reports where LLM complains about
> inconsistencies after IO errors or other catastrophic failures are rather
> frequent. I think that would be a good candidate for an ext4 specific
> prompt for LLMs to explain to it that after metadata IO failure filesystem
> inconsistencies are expected and we should just strive to limit lost data.
> 
> On Sun 09-08-26 13:45:09, Guanghui Yang wrote:
>> I am looking for clarification about the intended orphan handling when a
>> truncate fails after its journal transaction has been restarted.
>>
>> I reproduced the following using the official kernel.org Linux v6.14
>> source:
>>
>> - a large truncate naturally triggers jbd2_handle_restart()
>> - after the restart, a block-layer fault makes ext4_read_bh() return -EIO
>> - ext4_ext_truncate() and the truncate syscall return -EIO
>> - the restarted transaction is committed on disk
>> - before journal replay, e2fsck -fn reports that the orphan file contains
>>   no orphan entries
>> - the inode has i_size 0 but still has allocated blocks beyond EOF
>> - mount-time journal recovery completes, but the inconsistency remains
>>
>> In ext4_truncate(), an error from ext4_ext_truncate() jumps to out_stop.
>> For an inode with a nonzero link count, that path calls
>> ext4_orphan_del(handle, inode) regardless of the error.  In this run, the
>> committed post-restart transaction contains the orphan-file block, and the
>> pre-recovery check reports that the orphan file is clean.
>>
>> The comment above ext4_truncate() says that an incomplete truncate can be
>> restarted from ext4_orphan_cleanup() after a crash.  Should the on-disk
>> orphan entry therefore be retained when block removal fails after the
>> entry has been added?
>>
>> There is a second part to the recovery contract that I am unsure about.
>> The EIO marks the filesystem with EXT4_ERROR_FS, and
>> ext4_orphan_cleanup() skips orphan recovery in that state.  Is an e2fsck
>> repair the intended outcome for this class of error, or should ext4 keep
>> enough orphan state for mount-time recovery to finish the truncate?
> 
> This is expected. If you hit IO error on metadata, all bets are off wrt
> filesystem consistency. Running e2fsck to fix the filesystem is the only
> way to establish filesystem consistency again. So there's nothing to fix in
> the kernel really as the fact that an inode with blocks beyond EOF is not
> on orphan list is just a little nuissance...
> 
> 								Honza

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.

Thanks,
Yi.