On Thu, May 09, 2002 at 11:16:36AM -0500, Eric Sandeen wrote:
> On Thu, 9 May 2002, Ragnar Kjørstad wrote:
>
> > Unfortenately it doesn't solve our problem. I've run the whole process
> > in the debugger, and:
>
> Darn...
> (You've rebuilt & reinstalled all of the relevant userspace, I guess?)
I didn't "install" it, but am running it locally from the CVS-dir. And
yes, I did a make clean first.
> > Shoud it be changed to "error = 1;" ? Or a different possitive
> > error-code? AFAICT if we set error to a possitive value it will be
> > returned all the way back to zero_log. This will warn that the head/tail
> > is not found, but will zero the log anyway, and repair should go on...
>
> Yep, this does look a bit odd... I'll have to take some time to
> look at this, I'm not that familiar with the log recovery code...
> arbitrarily setting it to 1 probably isn't right (that's a specific
> error code...)
>
> Unfortunately there's a lot going on right now, no guarantees about how
> soon I can try to sort this out - looks like you're getting a pretty
> good handle on it already, though. :)
When I did the propsed change the xfs_repair was able to continue, but
of course the fix is "wrong" as the problem has nothing to do with
EPERM. (if the error is supposed to be an errno-type error-code)
Also, this just "fixes" the error-handling when the log can not be
parsed - it does not address the actual parsing of the log. It should be
noted that "xfs_repair -L" was run on the filesystem earlier, because
the filesystem could not be mounted.
Anyway; the filesystem now mounts, and some data is left. Unfortenately
the fs is very damaged (most of the directory-structure and I fear a lot
of the data is gone). Is there anything more that can be done, or is
what's lost lost?
Also I think it's strange that so much data was lost if it was only the
log that was corrupted.
--
Ragnar Kjørstad
Big Storage
|