> >>> This one looks good.
> >>
> >> Hm now that I think of it perhaps I should remove the explicit
> >> _check_scratch-es if they happen at the end of the run, just to
> >> try to speed things up.
> >
> > *nod*
>
> I'll send as another patch; I don't think there are really very
> many TBH.
>
> >>>> Also recreate lost+found/ in one test so that e2fsck doesn't
> >>>> complain.
> >>>
> >>> This one I can't make any sense of. Care to send it separately
> >>> with a good explanation?
> >>>
> >>
> >> Ok, sure.
> >>
> >> Basically, test does an rm -rf of the scrach mnt, but e2fsck
> >> thinks that a missing lost+found/ is cause for complaint and a
> >> failure exit code, which then stops the tests :(
> >
> > Shouldn't e2fsck be fixed? i.e. if you have a corrupted filesystem
> > and it's missing lost+found, how are you expected to create it? by
> > mounting your corrupted filesystem and modifying it and potentially
> > making the corruption worse?
>
> No, e2fsck fixes it, but reports that as an exit error condition
> even if nothing else is found.
>
I know lots of users who use to just delete lost+found directory, so making the
lack of l+f an error is wrong.
IMHO, there is no reason to report an error when a l+f is not found, unless you
need to recover orphan'ed inodes, I've never seen any other usage for it, unless
during FS recovery time. (maybe I lack some knowledge of another usages for
lost+found directory?)
So, I believe that might be useful to print a warning about it, but consider it
as an error is wrong IMHO.
--
Carlos
|