xfs
[Top] [All Lists]

Re: things to do in brooklyn when your filesystem is dead

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: things to do in brooklyn when your filesystem is dead
From: "Nathan J. Mehl" <memory@xxxxxxxxx>
Date: Tue, 15 Jan 2002 22:33:12 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20020114113445.D24972@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Mon, Jan 14, 2002 at 11:34:45AM +1100
Mail-followup-to: Nathan Scott <nathans@xxxxxxx>, linux-xfs@xxxxxxxxxxx
References: <20020112122144.R15376@blank.org> <20020114113445.D24972@wobbly.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
In the immortal words of Nathan Scott (nathans@xxxxxxx):
> 
> On Sat, Jan 12, 2002 at 12:21:44PM -0500, Nathan J. Mehl wrote:
> > ...
> > At this point, I am stymied.  xfs_repair will not progress beyond the
> > log-clearing step.
> 
> Can you tell me the exact error message you see?
> 
> Is it:
> "xlog_find_tail returned error X"?

Yup!  The error was, and is:

        Phase 1 - find and verify superblock...
        sb root inode value 18446744073709551615 
                inconsistent with calculated value 13835051870529257600
        resetting superblock root inode pointer to 18446744069414584448
        sb realtime bitmap inode 18446744073709551615 
                inconsistent with calculated value 13835051870529257601
        resetting superblock realtime bitmap ino pointer to 18446744069414584449
        sb realtime summary inode 18446744073709551615 
                inconsistent with calculated value 13835051870529257602
        resetting superblock realtime summary ino pointer to 
18446744069414584450
        Phase 2 - using internal log
                - zero log...
        XFS: Log inconsistent (didn't find previous header)
        XFS: failed to find log head
        
        fatal error -- xlog_find_tail returned error 5


> If so, I think this is a recently-introduced repair bug - I'll
> check in a fix shortly & you should be able to proceed on with
> xfs_repair.

Okay, I am a touch frightened to do just that.  The output from
xfs_repair -n is, uh, copious.  At ~600k, I won't spam the list with
it, but it can be perused here: http://blank.org/memory/xfs_repair.out.txt

I'm especially worried about:

     entry "tmp" at block 0 offset 96 in directory inode 128 references
     non-existent inode 20971648
             would clear inode number in entry at offset 96...
     entry "dev" at block 0 offset 112 in directory inode 128 references
     non-existent inode 25165952   
             would clear inode number in entry at offset 112...
     entry "bin" at block 0 offset 160 in directory inode 128 references
     non-existent inode 67109191   
             would clear inode number in entry at offset 160...
     entry "home" at block 0 offset 176 in directory inode 128 references
     non-existent inode 83886263  
             would clear inode number in entry at offset 176...
     entry "lib" at block 0 offset 192 in directory inode 128 references
     non-existent inode 88080769   
             would clear inode number in entry at offset 192...
     entry "mnt" at block 0 offset 208 in directory inode 128 references
     non-existent inode 96469292   
             would clear inode number in entry at offset 208...
     entry "opt" at block 0 offset 224 in directory inode 128 references
     non-existent inode 109052059  
             would clear inode number in entry at offset 224...
     entry "root" at block 0 offset 240 in directory inode 128 references
     non-existent inode 113246387 
             would clear inode number in entry at offset 240...
     entry "sbin" at block 0 offset 256 in directory inode 128 references
     non-existent inode 117440698 
             would clear inode number in entry at offset 256...
     entry "misc" at block 0 offset 272 in directory inode 128 references
     non-existent inode 75508160  
     
There are quite a lot of errors of that sort, but right there it looks
like my entire root directory is toast.

Is there anything that can be done manually to avoid this, or should I
just let xfs_repair do its job and salvage what I can from lost+found?

-n

------------------------------------------------------------<memory@xxxxxxxxx>
SENDING JUNK EMAIL TO MY ADDRESS CONSTITUTES YOUR LEGALLY-BINDING ACCEPTANCE 
OF MY OFFER TO REMOVE BOTH OF YOUR NIPPLES WITH AN ORBITAL SANDER.
                                                              (--Andy Ihnatko)
<http://blank.org/memory/>----------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>