All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: xfs@oss.sgi.com
Subject: Re: Badness in key lookup (length)
Date: Wed, 26 Nov 2008 09:51:58 +0100	[thread overview]
Message-ID: <200811260951.58472.Martin@lichtvoll.de> (raw)
In-Reply-To: <492C9D65.2080302@sgi.com>

Am Mittwoch 26 November 2008 schrieb Timothy Shimmin:
> Martin Steigerwald 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.
> >
> > xfs_check had stuff like
> >
> > agi unlinked bucket 0 is 8620800 in ag 0 (inode=8620800)
> > agi unlinked bucket 1 is 1181377 in ag 0 (inode=1181377)
> > agi unlinked bucket 2 is 8628866 in ag 0 (inode=8628866)
> > agi unlinked bucket 3 is 8620611 in ag 0 (inode=8620611)
> > agi unlinked bucket 4 is 1181380 in ag 0 (inode=1181380)
> > agi unlinked bucket 5 is 7711173 in ag 0 (inode=7711173)
> > agi unlinked bucket 6 is 7711174 in ag 0 (inode=7711174)
> > [...]
> > allocated inode 207025 has 0 link count
> > allocated inode 207029 has 0 link count
> > allocated inode 207118 has 0 link count
> > allocated inode 7711173 has 0 link count
> > allocated inode 7711174 has 0 link count
> > allocated inode 7711197 has 0 link count
> >
> > Which are due to references to deleted files AFAIK.
>
> Yep, inodes which were unlinked but still had references to them
> when the filesystem was taken down without cleanly unmounting.
> There is a hash table of buckets which point to linked lists of
> unlinked inodes. These are then supposed to be cleaned up during the
> log-replay stage on mount.
> I presume (sorry for asking but just checking :-) that you mounted the
> filesystem first - you would have gotten an error message if there was
> a dirty log anyway. And if you didn't mount first, did you get the
> error message? Just curious.

I did mount first ;-). I know its better to avoid xfs_repair -L ;-)

Indeed it was not unmounted cleanly:

Nov 25 13:16:39 shambhala kernel: XFS mounting filesystem sda5
Nov 25 13:16:39 shambhala kernel: Starting XFS recovery on filesystem: 
sda5 (logdev: internal)
Nov 25 13:16:39 shambhala kernel: Ending XFS recovery on filesystem: sda5 
(logdev: internal)

I wonder about those "Badness in key lookup (length)" messages of 
xfs_repair 2.9.8 touch.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2008-11-26  8:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-25 22:02 Badness in key lookup (length) Martin Steigerwald
2008-11-26  0:11 ` Barry Naujok
2008-11-26  8:58   ` Martin Steigerwald
2008-11-26  0:50 ` Timothy Shimmin
2008-11-26  8:51   ` Martin Steigerwald [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-11-25 22:03 Martin Steigerwald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200811260951.58472.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.