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.
> 
> Regards,
>         -is

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 
of.

Can anybody clarify?

  --Dwight Tuinstra
    tuinstra@clarkson.edu