On Mon, 5 Jan 2004, Daniel Palmer wrote:
> So I un-mounted the filesystem and ran xfs_repair on it:
>
> rei:/# xfs_repair /dev/hdb1
...
> Phase 3 - for each AG...
> - scan and clear agi unlinked lists...
> - process known inodes and perform inode discovery...
> - agno = 0
> - agno = 1
> - agno = 2
> correcting nblocks for inode 44179985, was 0 - counted 8
...
> Phase 4 - check for duplicate blocks...
> - check for inodes claiming duplicate blocks...
> - agno = 0
> - agno = 1
> - agno = 2
> data fork in regular inode 44179985 claims used block 3013232
> correcting nblocks for inode 44179985, was 8 - counted 0
...
> Phase 7 - verify and correct link counts...
> corrupt dinode 44179985, extent total = 1, nblocks = 0. Unmount and run
> xfs_repair.
> fatal error -- couldn't map inode 44179985, err = 990
That looks a little odd, repair can't seem to decide how many
blocks that inode should have, waffling between 8 and 0.
does the -v option give you any more interesting info?
how big is this filesystem, btw, and what does xfs_info output
look like.
-Eric
|