redden@ttidca.TTI.COM (John Redden) (03/08/88)
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