[PATCH] f2fs: return -EIO for a lost inode block after cp_error

[PATCH] f2fs: return -EIO for a lost inode block after cp_error

[Daeho Jeong]

From: Daeho Jeong <daehojeong@google.com>

After cp_error, dirty node caches are dropped without being written.
If such an inode was never written, its NAT entry is still NEW_ADDR,
and reading its inode block returns -ENOENT.

f2fs_get_dnode_of_data() passes that -ENOENT up, and callers take it
as a hole. Since the inode block is missing, the next offset can only
advance one block, so fiemap walks block by block up to maxbytes,
about 2^30 blocks, while holding the inode lock. It took hours in a
power-off recovery test after shutdown and blocked unlink and umount
on the file.

Return -EIO instead of -ENOENT when the inode block itself is missing
after cp_error or shutdown. A missing direct or indirect node is still
reported as -ENOENT.

Signed-off-by: Daeho Jeong <daehojeong@google.com>
---
 fs/f2fs/node.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index be14dfa31e5..55008f18afd 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -832,8 +832,20 @@ int f2fs_get_dnode_of_data(struct dnode_of_data *dn, pgoff_t index, int mode)
 
 	if (!dn->inode_entry) {
 		nentry[0] = f2fs_get_inode_cache(sbi, nids[0]);
-		if (IS_ERR(nentry[0]))
-			return PTR_ERR(nentry[0]);
+		if (IS_ERR(nentry[0])) {
+			err = PTR_ERR(nentry[0]);
+			/*
+			 * cp_error drops dirty node caches, so the inode block
+			 * of an inode that was never written reads as NEW_ADDR
+			 * and returns -ENOENT. It is not a hole; the inode is
+			 * gone. Callers treat -ENOENT as a hole and keep
+			 * looking block by block (e.g. fiemap up to maxbytes).
+			 */
+			if (err == -ENOENT && (f2fs_cp_error(sbi) ||
+					is_sbi_flag_set(sbi, SBI_IS_SHUTDOWN)))
+				err = -EIO;
+			return err;
+		}
 	} else {
 		nentry[0] = dn->inode_entry;
 	}
-- 
2.56.0.385.gd3acb90ef8-goog

Re: [f2fs-dev] [PATCH] f2fs: return -EIO for a lost inode block after cp_error

[Chao Yu]

On 10/13/26 02:22, Daeho Jeong wrote:
> From: Daeho Jeong <daehojeong@google.com>
> 
> After cp_error, dirty node caches are dropped without being written.
> If such an inode was never written, its NAT entry is still NEW_ADDR,
> and reading its inode block returns -ENOENT.
> 
> f2fs_get_dnode_of_data() passes that -ENOENT up, and callers take it
> as a hole. Since the inode block is missing, the next offset can only
> advance one block, so fiemap walks block by block up to maxbytes,
> about 2^30 blocks, while holding the inode lock. It took hours in a
> power-off recovery test after shutdown and blocked unlink and umount
> on the file.
> 
> Return -EIO instead of -ENOENT when the inode block itself is missing
> after cp_error or shutdown. A missing direct or indirect node is still
> reported as -ENOENT.
> 

Cc: stable@kernel.org
Fixes: 28607bf3aa6f ("f2fs: drop dirty node pages when cp is in error status")

> Signed-off-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,

Re: [f2fs-dev] [PATCH] f2fs: return -EIO for a lost inode block after cp_error

[patchwork-bot+f2fs]

Hello:

This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim <jaegeuk@kernel.org>:

On Mon, 12 Oct 2026 18:22:33 +0000 you wrote:
> From: Daeho Jeong <daehojeong@google.com>
> 
> After cp_error, dirty node caches are dropped without being written.
> If such an inode was never written, its NAT entry is still NEW_ADDR,
> and reading its inode block returns -ENOENT.
> 
> f2fs_get_dnode_of_data() passes that -ENOENT up, and callers take it
> as a hole. Since the inode block is missing, the next offset can only
> advance one block, so fiemap walks block by block up to maxbytes,
> about 2^30 blocks, while holding the inode lock. It took hours in a
> power-off recovery test after shutdown and blocked unlink and umount
> on the file.
> 
> [...]

Here is the summary with links:
  - [f2fs-dev] f2fs: return -EIO for a lost inode block after cp_error
    https://git.kernel.org/jaegeuk/f2fs/c/01ee16a7a758

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html