xfs
[Top] [All Lists]

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

To: "Nathan J. Mehl" <memory-xfs@xxxxxxxxx>
Subject: Re: things to do in brooklyn when your filesystem is dead
From: Nathan Scott <nathans@xxxxxxx>
Date: Mon, 14 Jan 2002 11:34:45 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20020112122144.R15376@blank.org>; from memory-xfs@blank.org on Sat, Jan 12, 2002 at 12:21:44PM -0500
References: <20020112122144.R15376@blank.org>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
hi,

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"?

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.

thanks.


> "xfs_repair -n" reveals thousands of inode errors;
> enough that I haven't had the patience to let it scroll through to the
> end.  (I gave up after about 4 minutes.)  
> 
> I'm prepared to assume that this FS is a total loss, and I expext that
> I've broken something badly by restoring an out-of-date (even if only
> by minutes) first 4k of the partition.  But just in case, I'm throwing
> it to the list -- does anybody know any tricks for persuading
> xfs_repair to cope with these sorts of situations?  The manpage makes
> tantalizing reference to "subopts", but the only one mentioned is
> "assume_xfs", which probably isn't helpful in this case.
> 
> Many thanks in advance,
> 
> -n
> 
> ------------------------------------------------------------<memory@xxxxxxxxx>
> "You don't qualify as the typical male snakebite victim: you weren't drinking,
> you don't have any tattoos, and you have all your teeth."
> <http://blank.org/memory/>----------------------------------------------------
> 

-- 
Nathan


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