xfs
[Top] [All Lists]

bad hash table ... would rebuild??

To: linux-xfs@xxxxxxxxxxx
Subject: bad hash table ... would rebuild??
From: Thomas Suiter <InsaneGeek@xxxxxxxxxxxxxxx>
Date: Tue, 19 Jun 2001 19:57:30 -0400
Sender: owner-linux-xfs@xxxxxxxxxxx
I'm sure this is easy to recover from and a simple xfs_repair will fix
it, but I'm wondering what exactly does this mean to me when I see this
big time alarm, or just (hopefully) correctable corruption due to
something outside of XFS?  I was unable to find any additional
information in the mailing list, faq, or web anywhere.

This is running off the cvs source tree from June 16

I first saw that my xfs cvs source tree had some funky things occurring
in it, doing an ls in different directories I received this:

# ls
ls: README: No such file or directory
ls: avl.c: No such file or directory
ls: avl64.c: No such file or directory
ls: init.c: No such file or directory

Which seemed fairly odd that someone knew something about a file but was
unable to find it, I did a xfs_repair on a mounted filesystem since

# xfs_repair -fn /dev/hdc5
Phase 1 - find and verify superblock...
...
Everything's fine until
...
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem starting at / ...
bad hash table for directory inode 5620157 (bad stale count): would
rebuild
bad hash table for directory inode 1532363 (bad stale count): would
rebuild
bad hash table for directory inode 7603417 (bad stale count): would
rebuild
bad hash table for directory inode 4968837 (bad stale count): would
rebuild
bad hash table for directory inode 2862249 (bad stale count): would
rebuild
        - traversal finished ...
        - traversing all unattached subtrees ...
        - traversals finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
#



<Prev in Thread] Current Thread [Next in Thread>
  • bad hash table ... would rebuild??, Thomas Suiter <=