Badness in key lookup (length)

Barry Naujok bnaujok at sgi.com
Tue Nov 25 18:11:09 CST 2008


On Wed, 26 Nov 2008 09:02:55 +1100, Martin Steigerwald  
<Martin at lichtvoll.de> wrote:

> Hi!
>
> I also checked my / XFS filesystem after that failed attempt to hibernate
> via TuxOnIce (see my mail "truncated files"). Well BTW this happened on a
> ThinkPad T42.
>
> While /home was fine, / had some rather minor - it seems - issues.  
> Whether
> they have been from today or from whenever - I do not know.

[snip]

> My questions:
>
> 1) Whats those Badness in key lookup messages? Anything to worry about?

Generally not - the xfsprogs cache indexes read blocks by offset and
I/O size. It will generate this warning if it encounters a read to the
same offset with different I/O size. Basically there to tell me that
there's a scenario where this may happen and should be fixed.

> 2) Why did xfs_repair -n after I ran xfs_repair yield yet another
> error "would have reset inode 94530 nlinks from 2 to 3"? Why didn't it
> appear in the first pass?

There are remote cases where the first pass does not get the nlinks
quite right - I would have needed a metadump before the first run to
isolate where it miscounted the nlinks. All problems like this in
the past have been related to lost+found.

> martin at shambhala:~/Zeit/xfs-probleme-2008-11-25> grep 94530
> xfsrepair-sda1-repair.txt
> martin at shambhala:~/Zeit/xfs-probleme-2008-11-25#1>
>
> 3) Any idea how these problems occured in the first time?

I think Dave pointed the cause out quite nicely :)

Regards,
Barry.

PS. Update the email address in your mailer to xfs at oss.sgi.com,
not xfs-linux at oss.sgi.com.



More information about the xfs mailing list