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-xfs@xxxxxxxxx>
Date: Wed, 16 Jan 2002 23:37:58 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20020116182420.F30220@xxxxxxxxxxxxxxxxxxxxxxxx>; from nathans@xxxxxxx on Wed, Jan 16, 2002 at 06:24:20PM +1100
Mail-followup-to: Nathan Scott <nathans@xxxxxxx>, linux-xfs@xxxxxxxxxxx
References: <20020112122144.R15376@xxxxxxxxx> <20020114113445.D24972@xxxxxxxxxxxxxxxxxxxxxxxx> <20020115223312.G15376@xxxxxxxxx> <20020116182420.F30220@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
In the immortal words of Nathan Scott (nathans@xxxxxxx):
> > 
> > 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?
> 
> That's pretty much the only option available at this point
> (unless you've used xfsdump/some other backup utility to keep
> a recent backup, and can use that in conjunction/instead).

Hm.  Okay, I seem to have run into another xfs_repair issue.  The cvs
code pushes past the log error, but there are a number of inodes that
it seems unable to properly clear/repair.  Every run of xfs_repair on
this fs since the first one produces the following output:

        http://blank.org/memory/repair.out

Subsequent iterations produce exactly the same output, referencing
exactly the same inodes.

Any notion why xfs_repair might be claiming to move directories and
files into lost+found but not actually doing it?

-n

-----------------------------------------------------------<memory@xxxxxxxxx>
"`G.I. Jane' is a demeaning, violent, bloody workout video. Some brief
nudity, bad language and a false sense of human resilience. Rated R." (--CNN)
<http://blank.org/memory/>---------------------------------------------------


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