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

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

On Mon, Aug 17, 2026 at 05:56:24PM -0500, Jan Kara wrote:
> 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...

If we want to let the system administrator know that they should run
fsck, then perhaps we should call ext4_error_inode() and return
EFSCORRUPTED instead of EIO.  In general, if we are in the middle of
modifying file system metadata, and we run into an error, we should
either try to back out the change so the file system is consistent.

HOWEVER, in this case, blocks beyond EOF is not really a file system
consistency issue, since you can get blocks beyond EOF by using the
fallocate system call with FALLOC_FL_KEEP_SIZE flag.

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

Unfortunately, it's a bit tricky to do that.  The problem is that
LLM's aren't consistent about how they handle AGENTS.md or CLAUDE.md
file.  Despite AGENTS.md being a standard promulgated by the LF's
Agentic AI Foundation, not all LLM harneses will read a AGENTS.md file
located a directory outside of the repository root directory.

So if we put LLM Harness directives in fs/ext4/AGENTS.md, some
harnesses (including Github's Copilot or OpenAI Codex) won't read it
unless there is an explicit request read it in the top-level AGENTS.md
file.  We could have the top-level AGENTS.md say that for any
file-system related code, please read fs/AGENTS.md, and then the
fs/AGENTS.md file could say that in case of a btrfs-related issue,
read fs/btrfs/AGENTS.md, and if it's an ext4-related, to please read
fs/ext4/AGENTS.md, etc.  It very quickly becomes a mess.

Worse, Claude has steadfastly refused to honor the AGENTS.md file
(although at least it will read CLAUDE.md file in subdirectories).  So
we'd have to have CLAUDE.md file be a symlink to AGENTS.md, or to have
an instruction in CLAUDE.md to read AGENTS.md.

Probably the best we can do is to put generic documentation in
Documentation/filesystems/ext4, meant for both humans and LLM's,
describing ext4's error handling philosophy, and hope the LLM
harnesses bothers to read it.

						- Ted