Subject: Re: lfs bootloader woes...
To: Ignatios Souvatzis <firstname.lastname@example.org>
From: Dwight Tuinstra <email@example.com>
Date: 10/17/2000 11:59:23
Ignatios Souvatzis wrote:
> On Mon, Oct 16, 2000 at 01:15:11PM -0400, Dwight Tuinstra wrote:
> > The first 8K of the slice is used for a boot block. It's
> > contents are *not* moved around. Immediately after the boot
> > block comes the first superblock, which contains (among
> > other things) the address of other superblocks in the file
> > system. See /usr/src/sys/ufs/lfs/README.
> yes, but not of the secondary bootblock. And the primary bootblock isn't
> big enough to contain enough ufs and lfs code to find the secondary through
> the filesystem. At least not on i386.
Thanks for the clarification. Incidentally, the situation of
the first superblock being immediately after the 8K boot block
might not be so clean-cut. This *is* the case when the file
system is instantiated, but I don't know if its guaranteed
after the system's been running for a while. Here's the puzzle:
* If superblocks are assigned to pre-determined segments
(and hence are at fixed disk addresses), then there's
the possibility those segments are never cleaned, and
the system won't get a chance to update the superblocks.
[ It's possible that this is gotten around by forcing
the cleaner to occasionally clean a superblock-
containing segment, or even just find the nearest
superblock and update that. ]
On the other hand ...
* If the superblocks are written at various occasions, and
into whatever segment is being written, then coherency
among the superblocks may get messy and possibly
seek-intensive. Relaxing coherency constraints would
give better performance and be easier to manage, but
could make crash restoration a real mess.
This came up in a recent discussion in our lab, and although
I've been reading the LFS code for a while I haven't yet
gotten to figuring out how it manages superblock placement
and coherency. The only thing immediately obvious is in
lfs.h, where in the definition of the superblock struct
one finds space for up to LFS_MAXNUMSB superblock addresses,
with LFS_MAXNUMSB set to 10. Since superblocks are essential
to the LFS checkpointing process, this implies that there are
at most 10 checkpoints ... or perhaps this means that only the
most recent 10 checkpoints (and superblocks) are kept track
Can anybody clarify?