On ma, 2007-01-08 at 12:23 +0200, Jyrki Muukkonen wrote:
> Got this error in phase 6 when running xfs_repair 2.8.18 on ~1.2TB
> partition over the weekend (it took around 60 hours to get to this
> point :). On earlier versions xfs_repair aborted after ~15-20 hours with
> "invalid inode type" error.
>
> ...
> disconnected inode 4151889519, moving to lost+found
> disconnected inode 4151889543, moving to lost+found
> corrupt inode 4151889543 (btree). This is a bug.
> Please report it to xfs@xxxxxxxxxxxx
> cache_node_purge: refcount was 1, not zero (node=0x132650d0)
>
> fatal error -- 117 - couldn't iget disconnected inode
>
> I've got the full log (both stderr and stdout) and can put that
> somewhere if needed. It's about 80MB uncompressed and around 7MB
> gzipped. Running the xfs_repair without multithreading and with -v might
> also be possible if that's going to help.
>
Some more information:
- running 64bit Ubuntu Edgy 2.6.17-10-generic
- one processor so xfs_repair was run with two threads
- 1.5GB RAM, 3GB swap (at some point the xfs_repair process took a bit
over 2GB)
- filesystem is ~1.14TB with about ~1.4 million files
- most of the files are in subdirectories by date
(/something/YYYY/MM/DD/), ~2-10 thousand per day
So is there a way to skip / ignore this error? I could do some testing
with different command line options and small code patches if that's
going to help solve the bug.
Most of the files have been recovered from backups, raw disk images etc.
but unfortunately some are still missing.
--
Jyrki Muukkonen
Futurice Oy
jyrki.muukkonen@xxxxxxxxxxx
+358 41 501 7322
|