http://oss.sgi.com/bugzilla/show_bug.cgi?id=424
Summary: xfs_repair ended with "fatal error -- couldn't map inode
53909610, err = 990"
Product: Linux XFS
Version: Current
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: xfsprogs
AssignedTo: xfs-master@xxxxxxxxxxx
ReportedBy: ja@xxxxxxxxxxxx
xfsprogs-2.7.2
kernel: SGI-XFS CVS-2005-09-21_05:00_UTC with ACLs, large block/inode numbers,
no debug enabled
I have corrupted XFS filesystem sda1. The compressed image is downloadable from
http://www.neton.sk/~ja/sda1.bz2 (436946 bytes). When I run xfs_repair on it I
get :
# xfs_repair -f sda1
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
correcting nblocks for inode 16152860, was 0 - counted 2
- agno = 4
correcting nblocks for inode 16791313, was 0 - counted 1
- agno = 5
- agno = 6
correcting nblocks for inode 25176869, was 0 - counted 2
correcting nblocks for inode 25176898, was 0 - counted 1
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
correcting nblocks for inode 53909610, was 0 - counted 1
- agno = 13
- agno = 14
- agno = 15
- 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
- deleting existing "lost+found" entry
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
data fork in regular inode 16152860 claims used block 1010064
xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0' failed.
Abort
Then I compiled xfsprogs with DEBUG=-DNDEBUG and got following output:
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
imap claims a free inode 131 is in use, correcting imap and clearing inode
- 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
- agno = 14
- agno = 15
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
data fork in regular inode 16152860 claims used block 1010064
correcting nblocks for inode 16152860, was 2 - counted 0
- agno = 4
data fork in regular inode 16791313 claims used block 1534352
correcting nblocks for inode 16791313, was 1 - counted 0
- agno = 5
- agno = 6
data fork in regular inode 25176869 claims used block 1796496
correcting nblocks for inode 25176869, was 2 - counted 0
data fork in regular inode 25176898 claims used block 2058640
correcting nblocks for inode 25176898, was 1 - counted 0
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
data fork in regular inode 53909610 claims used block 3369360
correcting nblocks for inode 53909610, was 1 - counted 0
- agno = 13
- agno = 14
- agno = 15
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 / ...
corrupt dinode 53909610, extent total = 1, nblocks = 0. Unmount and run
xfs_repair.
fatal error -- couldn't map inode 53909610, err = 990
The message about unmouting is confusing. The filesystem is not mounted. I can
mount and unmount it, but xfs_repair behaviour is still the same. From user
point of view the filesystem seems to be only light damaged. There are 4
unreadable files, but the rest is OK.
Is there way to repair this FS? Is possible to modify xfs_repair to handle such
kind of damage?
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|