Hey guys I could use some help here. I know there's probably a way to
fix this but I don't know what it is. I am running Debian testing with
a linux 2.6.9 kernel.
Last night some strange behavior started and I noticed messages from the
kernel and xfs. So I did a reboot with a Knoppix CD I had and tried
xfs_repair. After that I tried xfs_check. These were version 2.6.28 by
the way.
===========================================================================
root@ttyp0[knoppix]# xfs_repair /dev/hdb2
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
correcting nblocks for inode 109931154, was 0 - counted 1
- agno = 14
correcting nblocks for inode 120423310, was 0 - counted 12
- agno = 15
correcting nblocks for inode 128288145, was 0 - counted 1
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- clearing existing "lost+found" inode
- marking entry "lost+found" to be deleted
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
data fork in regular inode 109931154 claims used block 7613136
correcting nblocks for inode 109931154, was 1 - counted 0
- agno = 14
data fork in regular inode 120423310 claims used block 8137424
correcting nblocks for inode 120423310, was 12 - counted 0
- agno = 15
data fork in regular inode 128288145 claims used block 273104
correcting nblocks for inode 128288145, was 1 - counted 0
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- ensuring existence of lost+found directory
- traversing filesystem starting at / ...
rebuilding directory inode 128
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
corrupt dinode 109931154, extent total = 1, nblocks = 0. Unmount and
run xfs_repair.
fatal error -- couldn't map inode 109931154, err = 990
root@0[knoppix]# xfs_check /dev/hdb2
bad nblocks 0 for inode 109931154, counted 1
bad nblocks 0 for inode 120423310, counted 12
bad nblocks 0 for inode 128288145, counted 1
===========================================================================
|