* Timothy Shimmin <tes@xxxxxxx> [071221 00:38]:
> Jonathan C. Detert wrote:
> >* Timothy Shimmin <tes@xxxxxxx> [071220 18:49]:
> >>Jonathan C. Detert wrote:
> >>>I just want to clarify - I mean to ask:
> >>>
> >>> Is it possible that an xfs filesystem which is in use by an o.s.,
> >>> last mounted by the o.s. months ago, could have a corrupted log, and
> >>> yet keep functioning until such time as a remount of it is attempted?
> >>>
> >>Yes.
> >>The log is read on every mount. I don't believe we read it otherwise.
> >>On a mount we look for the log head and an unmount record etc. to decide
> >>whether to do a replay or not.
> >>So it could be corrupted and we would not know and we don't really care
> >>until the next mount.
-- snip --
> >>If you unmount it cleanly. Run repair on it before mounting it again.
> >>Then repair may find corruption when it tries to find the log head etc...
> >>to work out if the log is clean or not.
> >>i.e. in this case repair will try to read the log before you've tried
> >>to do a mount.
> >
> >So, how do you recover from a situation like i have, namely:
> >
> >1) the xfs file system is not currently mounted
> >2) an attempt to mount the xfs fs fails, complaining about log being
> > inconsistent or not a log
-- snip --
> Without doing anything fancy, you are stuffed.
> You need to clear the log and repair it using "xfs_repair -L"
> (the -L will zero the log and for linux write a log record in there).
>
> I was wondering that if only the end of the log was corrupted and that
> was not between the tail and the head, then one could write
> 0x00000255 (597 dec) at the start of each sector (which is the previous
> cycle#) where the corruption is.
> Then the recovery code would likely think that this was old
> data as it has the old cycle# (and hence ignore it).
> However, it is xmas breakup day and I'm too tired to try it out
> at the moment. :)
Merry Christmas, and have a good rest
> Was thinking of something like:
> xfs_io -c 'pwrite -b 512 -S 0x00000255 38889s 31s' sdb-xfs-log.fixup
> But that's not right. Sorry.
> And then I'm still not convinced about the tail numbers in many
> of the log records (particularly the head) anyway.
I have nothing to lose at this point. If you work out a best guess
sometime before January 5th, I will try it. If it works, there would be
much rejoicing around here.
Thanks for all your help so far.
--
Jon Detert
IT Systems Administrator, Milwaukee School of Engineering
1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A.
--
Linus Torvalds doesn't die, he simply returns zero.
|