4BSD file system structure

[Chris Torek]

Since no one has answered this one yet (gee, why not? :-) ):

In article <3410 at netcom.UUCP> hinton at netcom.UUCP (Greg Hinton) writes:
>First, what is the layout of the zero'th cylinder group?

Pretty much the same as any other.  There is no special case for it:

>According to <sys/fs.h>, BBLOCK & SBLOCK are "absolute disk addresses".
>Is that CSRG's way of saying "sector numbers"?

More or less.  These have been changed to BBOFF and SBOFF, in bytes,
so as to handle other sector sizes, but they still amount to 0 and 8K
bytes respectively.

>Does the zero'th cylinder group contain the usual complement of cg
>block, inode blocks and data blocks?

Yes.

>If so, doesn't the presence of the boot block throw things off?

No.  Each physical group of, e.g., 16 cylinders can be modeled thus:

	+----------------+
	|   data part 	 |
	| continued from |
	|  previous cg	 |
	|----------------|
	| cylinder group |
	|     stuff	 |
	| -- -- -- -- -- |
	|   data part	 |
	|  for this cg	 |
	+----------------+

Starting at the `cylinder group stuff', one moves downward some
distance to find the `data part'; this data part continues in the next
physical group (here the next 16 cylinders).  The last group usually
has less data than the rest, but the `missing' part that would normally
be in the next clump of 16 cylinders is straightforwardly represented
as `not free'.

The size of the `data from previous cg' is determined by the cyl group
number, and starts at 16K, leaving room for the boot block and the
master super-block.  It goes up by some amount for each physical group
of cylinders, so that the `cylinder group stuff' (which is, in order,
the super-block copy, the cylinder group data, the inodes, and then the
data) begins `further down' in each physical cg.  This puts its copy of
the super-block on a separate head, track, and/or cylinder from the
previous one.  With any luck, no matter what happens to the disk, at
least one super-block will remain intact, giving enough clues to
analyse the rest of the disk for files that also remain intact.

>Second, how does the on-disk inode (struct dinode in <sys/inode.h>)
>indicate that the last block in a file is a fragment?

It does not; it does not have to.  The `blksize' macro determines
the size of a file block, based entirely on the block's number and
the file's size:

#define blksize(fs, ip, lbn) \
	(((lbn) >= NDADDR || (ip)->i_size >= ((lbn) + 1) << (fs)->fs_bshift) \
	    ? (fs)->fs_bsize \
	    : (fragroundup(fs, blkoff(fs, (ip)->i_size))))

In other words, if the block number (we are talking 8K byte blocks if
this is an 8K/1K file system, e.g.) is >= NDADDR (12), or if this is
other than the very last block, the last block is not a fragment.  Otherwise,
the last block *is* a fragment; its size is the smallest number of
fragments that completely contains the last part of the file (after
all the previous full blocks are counted).  The last `fragment' can
have just as many fragments as a full block, in which case its size
is the same as fs->fs_bsize, but it could be smaller.

(Thus, files >= 48K (4k/any) or 96K (8K/any) never end in a fragment.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris