Hi Nathan,
I sent the follow report out at the beginning of this month. The report
is about that xfs_repair creates lost+found every time it runs, even on a
clean file system, and if crash happens while lost+found is created, the
root directory goes corrupted. It looks like making xfs_repair crash-safe
is hard. However, I'm wondering if you guys have fixed the creating
lost+found even on a clean fs part.
Thanks,
-Junfeng
On Fri, 3 Sep 2004, Nathan Scott wrote:
> Hi guys,
>
> On Thu, Sep 02, 2004 at 04:15:59PM -0500, Steve Lord wrote:
> > Junfeng Yang wrote:
> > >
> > >>>I suspect what you are doing with this change is making repair fail
> > >>>in the middle of creating the lost+found dir, repair always does that.
> > >>>
> > >
> > >
> > > you mean xfs_repair creates lost+found everytime it runs? I'm not sure if
>
> Thats correct.
>
> > > the crash happens in the middling of creating lost+found, as our checker
>
> For a clean filesystem, I think the only writes will be the log
> zeroing and the creation of lost+found.
>
> > > only sees block writes with little file system knowledge. We caught this
> > > warning automatically (w/o chaing the xfs_repair code).
> > >
> > > so is it true that in the rare case that xfs_repair fails in the middle of
> > > creating lost+found, '/.' can be wiped off? do you guys consider this as
> > > a bug?
> > Well, I don't work on xfs anymore really, I just watch from the sidelines.
> > It is a pretty small window in reality, but it probably says that while
> > repair is running the filesystem is vulnerable to machine outages.
> > Getting repair out of that hole would be a big job I suspect. It would
>
> Yep.
>
> > need to implement a journal and do all its work that way. Hmm, I cannot
> > remember if it actually does that for the most part to be honest.
>
> Nope, not even in libsim on IRIX. Only some of the xfs_log_*
> routines exist there, mainly the ones needed for xfs_logprint,
> the rest are stubbed out.
>
> Even if it implemented the log, we'd then have to start doing all
> writes O_SYNC (ouch), and other little things like that I suspect
> (a pinnable buffer cache in userspace, etc?). Hmmm.
>
> cheers.
>
> --
> Nathan
>
|