xfs-masters
[Top] [All Lists]

[xfs-masters] [Bug 424] New: xfs_repair ended with "fatal error -- coul

To: xfs-master@xxxxxxxxxxx
Subject: [xfs-masters] [Bug 424] New: xfs_repair ended with "fatal error -- couldn't map inode 53909610, err = 990"
From: bugzilla-daemon@xxxxxxxxxxx
Date: Wed, 28 Sep 2005 15:31:42 -0700
Reply-to: xfs-masters@xxxxxxxxxxx
Sender: xfs-masters-bounce@xxxxxxxxxxx
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.


<Prev in Thread] Current Thread [Next in Thread>
  • [xfs-masters] [Bug 424] New: xfs_repair ended with "fatal error -- couldn't map inode 53909610, err = 990", bugzilla-daemon <=