[Top] [All Lists]

Re: Badness in key lookup (length)

To: "Martin Steigerwald" <Martin@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: Badness in key lookup (length)
From: "Barry Naujok" <bnaujok@xxxxxxx>
Date: Wed, 26 Nov 2008 11:11:09 +1100
In-reply-to: <200811252302.55944.Martin@xxxxxxxxxxxx>
Organization: SGI
References: <200811252302.55944.Martin@xxxxxxxxxxxx>
User-agent: Opera Mail/9.52 (Win32)
On Wed, 26 Nov 2008 09:02:55 +1100, Martin Steigerwald <Martin@xxxxxxxxxxxx> wrote:


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.


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@shambhala:~/Zeit/xfs-probleme-2008-11-25> grep 94530

3) Any idea how these problems occured in the first time?

I think Dave pointed the cause out quite nicely :)


PS. Update the email address in your mailer to xfs@xxxxxxxxxxx,
not xfs-linux@xxxxxxxxxxxx

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