superblock offset under AT&T Unix

[John Redden]

We have mostly completed a port of System V Rel 3 to our own 68020
hardware and are now in the process of making some decisions that will
affect the final product.

In particular, we'd like some opinions from the net involving file
system related questions.

Before asking these questions, I want to supply the following information:

To allow using already existing file systems, we chose to have our pre-release
port initially support our old unix's file system. This filesystem is
a proper subset of the Release 3 filesystem with some positional
differences such that:

	1) All fields in our superblock are also in the S5r3 superblock.
	2) The order in which these fields appear differs from that in s5r3.
	3) The s5r3 superblock has the three additional fields:
		s_state, s_magic, and s_type.

	4) In our fblk structure, df_nfree appears after df_free[] rather
	   than before.

	5) NICINOD is 200 and NICFREE is 100. These are twice the values
	   supplied by ATT for the 3b2 in s5param.h.

	6) Our hardware block size is 1Kb.  Our boot block is 1k in length
	   starting at byte 0, and the superblock is 1k in length starting
	   at byte 1024.  Thus we set SUPERBOFF to 1024.

	7) "5" and "6" above are the reasons that both our superblock
	   and our fblk's are larger than 512 bytes.

	8) In-field os update will be performed via network control with
	   no human intervention or presence.  Among other things this
	   means in-place file system conversion.

We intend to revert our s5filsys.h and s5fblk.h includes back to what ATT
supplied us, but have not yet decided on constants for s5param.h

We have prepared two versions of our port using the original includes
from ATT. In the first version, NICINOD is 100, NICFREE is 50, the
superblock is at offset 512 and is 512 long, and our boot block is at
offset 1024. Our disk blocks are still 1024, so fblks are only half
full.

In the second version, we have kept NICINOD at 200, NICFREE at 100,
boot block at 0, and superblock at 1024 of length 1024 (made exactly
so by adjusting s_fill).

Both versions work, but are obviously incompatible.  We do not intend
to support more than one file system type in the near future, although
we may add the BSD fast file system at a much later date.

What we need to decide now is whether to take the first version or
the second version (or perhaps parts of each) for our final product.

Questions that have been raised are:

1) Is there any reason that we cannot call the second version
   described above a "system v" based file system (Keeping in mind
   by AT&Ts legal definition on a System V file system can run on a 3B2 and
   we run on a 68020 based machine)?

2) fsck contains it's own #define of SBSIZE, requiring an ifdef.
   Other changes are necessary to fsck as well, since it lacks
   defines for m68k (although u370, pdp-11, 3bx are there), so we
   can't avoid making modifications to it.

   What other programs bypass the file system specific include files
   in this manner?
	   
3) Can you think of any vendor supplied software that should care
   about the superblock offset or superblock size?

4) Can you think of any reason why we would not want to have a 1k
   superblock starting at offset 1024?
	   
5) What about the values of NICINOD and NICFREE as supplied for the
   3b2 in s5param.h? The default values result in an fblk structure
   occupying less than half a disk block. We have the room to increase
   these for better performance, and perceive not increasing them as
   unnecessarily wasteful.  Is there any reason why we should
   not do so?

6) How important is using s_fill to make sizeof(struct filsys) be
   exactly == 1024?  (or exactly == 512).  If we just increased
   NICINODE and NICFREE to our old values, and did not adjust s_fill,
   this would make the superblock be 904 bytes long.  What could this
   break?

7) What are the pros and cons of adjusting s_fill to make sizeof 
   (struct filsys) be exactly 1024?

8) How do the above issues affect our ability to call our port System V
   compliant?

9) How stable is the file system switch?  There are some comments in
   the code indicating the possibility of changes in the fs switch
   interface.  Would these be major rework items? Just additional
   fields?  I'd like to see some intelligence added to allow figuring
   out which of several (possibly radically different) disk resident
   file system types are being mounted. Defaulting to the same type
   as the root file system can result in file system corruption if
   the default is wrong.  

10) Can you think of potential pitfalls we should watch out for during
    in-field conversion?  Our present conversion plan calls for
    loading the necessary coff binaries followed by one of the two
    following approaches:

    a) run a program that completely rebuilds the filesystem (suberblock
       and free list in place).
     or:
    b) run a program that just rebuilds the superblock and invokes
       fsck to rebuild the free list.

    In both cases, all filesystems except root will be unmounted with
    conversion of root taking place last.  In the second case, fsck
    will execute it's normal "reboot after fixing root" code.  A special
    version of our old (non system V based) os that understands both file
    system types and present on a spare partition will be automatically
    booted if problems are encountered in rebooting from the converted root.

10a) Instead of the spare os described just above, would it make more
     sense to just have our initial release understand both file system
     types through the file system switch?  This could be handled by
     replacing the hard hardcoded call of s5rmount in srmountfun() with
     something like "(*rootmount)(iflg);",  where rootmount pointed at
     a routine for mounting our old file system, but which checked for the
     root being the new file system type, in which case it would change
     the value of "rootmount" to refer to "s5rmount", change the similar
     pointer "rootumount" to refer to "s5rumount",  do some trivial cleanup
     and then call s5rmount.  We have a system already built that does this
     but there is resistance to the idea of continuing to support our old
     file system type even for just the initial release.

11) Do you see other problems we haven't anticipated? Do you have any
    other comments or suggestions?
   
Legal Disclaimer:

System V and Unix are registered names and property of AT&T.  References to 
System V refer to a System V based system under full source rights purchased
from AT&T and are protected with the appropriate security mechanisms.  Names
referenced in this mail gram are for a technical discussion only of Unix 
based systems and do not constitute a disclosure of AT&T property.

The opinions expressed are soley of the author(s).


Michael Bloom - staff member
John Redden- manager unix development