[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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 system.
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
On 07/12/2014 10:52 AM, David Holland wrote:
A long time ago (in
> 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 |