[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
You probably want to do some testing of the roll-forward code. Back when
I was whacking on LFS I noticed that running fsck on a dirty filesystem
appeared to cause more problems than it fixed. And running multiple
passes caused even more damage.
On Sat, 12 Jul 2014, Konrad Schroder wrote:
> I'm sure it does need a complete overhaul. What I did with fsck_lfs was
> essentially to adapt the parts of fsck_ffs that check what is common to the
> two FSs (directories, inodes, block addresses, sizes, etc.) to LFS's way of
> locating inodes, as well as the additional constraint that blocks should not
> lie in free segments.
> The reason for checking the filesystem before rolling forward is that,
> roll-forward being relatively untested, I wanted to check that the older
> checkpoint was consistent before checking the newer (remember that the newer
> checkpoint's consistency can't be taken for granted). If the older checkpoint
> was not consistent, it should be fixed before rolling forward. If it was
> consistent (either checked or, in the case of fsck -p, assumed) but
> roll-forward between the two checkpoints failed, the older one was a valid
> state of the filesystem; if it succeeded, the newer checkpoint was a valid
> state of the filesystem. Rolling forward past the newer checkpoint requires
> resizing inodes etc. and only makes sense in the context of a consistent file
> So, I have no doubt that rewriting fsck_lfs from scratch and/or cleaning it up
> make perfect sense, but there is some reasoning in the madness too. In
> particular, I don't agree that fsck_lfs should be limited to recreating the
> ifile; it needs to be able to recover as much as possible in the event of bad
> blocks as well.
> The in-kernel roll forward is disabled because it is broken. It worked
> briefly before LFSv2, but I never got back to fixing it after it broke. I
> think Dr. Seltzer must be thinking of another OS, since 4.4lite2 did not
> contain any roll forward code at all. It's also worth asking whether the user
> should have control over when and whether roll-forward occurs, which is
> straightforward with a userland fsck but more difficult if it is in-kernel.
> Take care,
> On 07/12/2014 10:52 AM, David Holland wrote:
> > A long time ago (in
> > <Pine.NEB.4.64.1002090351150.23795%mail.netbsd.org@localhost>)
> > you wrote:
> > > I do disable fsck_lfs. It usually causes more problems than it
> > > solves. It needs a complete overhaul. It tries to act like
> > > fsck_ffs instead of validating segment checksums and regenerating
> > > the ifile.
> > A quick look at fsck_lfs with this in mind suggests that it's full of
> > bull, yes. For some reason it tries to check the fs *before* rolling
> > forward; it seems unlikely that this would ever work properly.
> > However, as far as I can readily tell the obvious problems are limited
> > to doing a full fsck, and all that the reboot time fsck -p does is
> > roll forward. Given that the kernel roll forward code is disabled by
> > default (does anyone know why? Margo Seltzer says it shouldn't be),
> > disabling boot-time fsck seems like a bad idea.
> > Unless the roll-forward code is broken, in which case it should be
> > fixed. I don't see any PRs on it though.
> > Anyhow, in the absence of any specific information, unless testing
> > turns up some issues, I'm inclined to revert the commit I just made
> > and re-enable fsck_lfs -p.
Main Index |
Thread Index |