[net.os] Orphaned Response

smith@uoregon.UUCP (smith) (12/30/85)

> I am familiar with the directory and inode structure on UNIX (4.2 BSD)
> and with the directories and file allocation table on PC-DOS/MS-DOS,
> so I have an idea of how a file is allocated disk space (and placed in
> the right directory) on those systems.  
> However, I am not familiar with VMS, TOPS-10, OS-9 or the UNIClones.
> How do they go about it?  They all have hierarchical (sp?) file systems,
> so there should be some similarities between some of them.  Right?

I am familiar with TOPS-10, so here is the scoop there.  TOPS-10 is an
old operating system (mid 60's) with concepts drawn from the MIT Multics
System, the Berkely SDS 940, and the Stanford PDP-1 based timeshared
system.  Later, concepts were drawn from the BBN TENEX improvements to
TOPS-10 and integrated into the DEC supplied TOPS-10 product, including
hierarchical directory structures.

The TOPS-10 file system consists of one or more file stuctures.  A file
structure is a logically named collection of one or more physical disk
units.  Each file structure is rooted by a Master File Directory (MFD).  
Entries in directories consist of a file name (or directory name) and 
a pointer to the Retrieval Information Block (RIB) for that file (or 
directory).  The normal contents of the MFD are User File Directory (UFD)
entries for each user with files on the file structure.  Each user has
a UFD that is the "home directory" for that user.  This "home directory"
consists of entries that point to files or Sub-File Directories.  Each
Sub-File Directory can contain files or more Sub-File Directories.  This
nesting provides the tree structure, but is limited to 5 levels of sub-
directories.  The "location" of a file in the directory structure is 
determined by the directory that points to the RIB for the file.  A file
then, has no location other that the location of its parent.  Files can
only be owned by one directory (unlike UNIX).  When a file is created
in a specific directory (if no directory is specified, then the current
directory is used as in UNIX), an entry is made in the directory with
the name of the file, and disk space is allocated for the RIB for the
file and some file information is placed in the RIB.  The RIB provides
for a place to store information about a file (creation date/time, version
information, file size, mode file was written, etc.).  The RIB seems
to be somewhat like an inode in UNIX except for this ability to store all
sorts of useful information about the file.  If any of this makes any sense,
it should be obvious that to delete (remove) a file, all one has to do is
to remove the entry for the file from the directory that owns that file, and
the file can no longer be referenced.  I think that this about covers
how one locates a file in TOPS-10. 

As for how disk space is allocated, it works the same for both files and
directories.  The smallest section of a disk that can be read or written
is called a disk block.  A disk block is 128 words (36 bits = one word)
which is 640 7-bit characters.   Space is allocated on a disk in an
integral number of disk blocks called clusters.  The size of a cluster 
is definable by the system administrator or system programmer when a
disk structure is defined and created.  Usually, the number of blocks
per cluster is fairly small (3 to 10 blocks/cluster).  There is another
parameter that is definable that is the minimum number of blocks to try
to allocate any time space is allocated.  This is usually in the 30 to 100
block range.  Any un-used blocks when the file is closed is released
down to the last cluster boundry.  A map of which clusters are used and
free is contained in a table called the Storage Allocation Table (SAT).
A copy of this table exists both on disk and in core.  TOPS-10 is
conservative about updating the SAT and writing files so that it is rare
to have the SAT claim a block is free when it is in use.  It is fairly
common to have the SAT claim that a block is in use when it is actually
free.  There is a utility to correct this problem.  

For a more complete (and probably less confusing) explaination, see
chapter 12 of the DEC TOPS-10 monitor calls manual volume 1.

Dale Smith
UUCP:  {ucbvax,decvax}!tektronix!uoregon!oregon2!120
  or:  {ucbvax,decvax}!tektronix!uoregon!uo-vax1!smith