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
|