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