xfs
[Top] [All Lists]

2.6.34-rc3: inode 0x401afe0 background reclaim flush failed with 11

To: xfs@xxxxxxxxxxx
Subject: 2.6.34-rc3: inode 0x401afe0 background reclaim flush failed with 11
From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
Date: Fri, 9 Apr 2010 14:05:14 -0700 (PDT)
User-agent: Alpine 2.01 (DEB 1266 2009-07-14)
Hi,

while running some filesystem benchmarks, this happend in my logs when 
bonnie++ was running:

[14610.114155] Filesystem "md0": inode 0x401afe0 background reclaim flush 
failed with 11
[14610.114171] Filesystem "md0": inode 0x401afe1 background reclaim flush 
failed with 11
[14610.114183] Filesystem "md0": inode 0x401afe2 background reclaim flush 
failed with 11
[...]

...and so forth for a couple of inodes.

I can reproduce this pretty reliably with bonnie++ now. This did not 
happen with 2.6.33, but the bonnie++ version has been upgraded too, so I'm 
still not sure if this is a real regression.

I've put a few details on http://nerdbynature.de/bits/2.6.34-rc3/xfs/

Is this something to worry about?

Thanks,
Christian.

PS: Why is the inode shown in hex and not in decimal? Would something 
like this do:

diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c
index 05cd853..30c7bcb 100644
--- a/fs/xfs/linux-2.6/xfs_sync.c
+++ b/fs/xfs/linux-2.6/xfs_sync.c
@@ -825,7 +825,7 @@ xfs_reclaim_inode(
         */
        if (error && !XFS_FORCED_SHUTDOWN(ip->i_mount)) {
                xfs_fs_cmn_err(CE_WARN, ip->i_mount,
-                       "inode 0x%llx background reclaim flush failed with %d",
+                       "inode 0x%llu background reclaim flush failed with %d",
                        (long long)ip->i_ino, error);
        }
 out:


[0] http://nerdbynature.de/benchmarks/v40z/2010-04-06/
-- 
BOFH excuse #329:

Server depressed, needs Prozac

<Prev in Thread] Current Thread [Next in Thread>