Forth File System Specification

o  The final 16 bytes of each block are reserved for disk management/file system
   administration.  This space is used as follows:

      - bytes 4092-4095: next block in file
      - bytes 4088-4091: previous block in file
      - bytes 4084-4087: parent block
      - bytes 4082-4083: content byte count, this block
      - bytes 4080-4081: file system status bits

o  With the exception of the anchor block (described below), bytes 0000-4079 of all
   blocks are available for arbitrary user or file system content.

o  File directories will just be files, with particular content.  So, the final 16
   bytes of directory blocks will be as described above.  The file system status bits
   noted above will identify each block as user data, directory data, internal b+tree
   node, etc. etc.

o  New items will be added to directory blocks beginning at the highest free address
   and working down.  Each directory entry will be laid out as follows:

      - Four bytes specifying a block number, which will be
            - The first content block of the file, or
            - The root of a b+tree mapping the file
        The block's file system status bits will specify which of these options is
        in play.
      - Five bytes specifying the file's total size in bytes
      - Three bytes of flags/status.
      - Four bytes reserved for future use.
      - A Forth counted string specifying the file's name
      - Pad bytes to 32-bit align the following entry.

   Assuming the average counted name string requires eight bytes, a single block's
   usable space will hold 170 directory entries - most directories will need no more
   than a single block.

o  The unspecified flags/status bits can specify permissions, etc.

o  Directory entries will be packed, with each new item being added just before the
   previously added item.  The content count word will allow us to determine where
   these items begin in the block, and we can then search them linearly to find a
   name match.  If more entries than one block can hold are needed, blocks can be
   added to the directory "file" using the administrative fields at the end of the
   block.

o  The root of the file system (path /) will begin at the "anchor block" - the only
   block in the system that must be at a pre-established block number.  The anchor
   block will have the usual administrative fields at the end.  Beginning with byte
   offset 0000, further content will be arranged as follows:

      - Bytes 0000-0007: "Magic number" so we can identify this drive as a valid
        drive.
      - Bytes 0008-0011: First block in the block allocation pool
      - Bytes 0012-0015: First block after the block allocation pool
      - Bytes 0016-0019: First block on the "free block list"
      - Bytes 0020-0023: First block of the "frontier" (remaining virgin pool)
      - Bytes 0024-0027: Reserved for future use
      - Bytes 0028-0031: A number N specifying a bootable image count
      - N 8-byte fields, each as follows:
            - 4 bytes specifying a "first block in image"
            - 4 bytes specifying a "last block in image"
      - First directory entries of the / directory (filling down from the top)

   The fields above are sufficient to allow the operation of a simple fixed size block
   allocator, and will also allow us to carve off the high end of the disk for custom
   management, outside of the file system.  Note that the "content byte count" used
   in the anchor block will *not* include the special data in bytes 0000-0023, or the
   bytes used by bootable image ranges.

    Note that directories other than / will have an entry with name ".." identifying
    the parent directory.

o  The structures defined above will allow us to create arbitrary file hierarchies,
   find files given a path spec, and seek through files to any content offset.

o  Each file can (later) have a b+tree associated with it, which will let us do
   in-file seeks at an accelerated pace.  Each file block's "parent" field will be
   used as an access point to this b+tree, and blocks within the b+tree will be
   linked to siblings with the prev and next fields and to their parents with the
   parent field.  The b+tree features are optional and not required for initial use.

o  The "reserved" field in directory entries has no immediate purpose, but ultimately
   could be used to supply per-file "auxiliary information."  For example, this might
   include a schema for database tables, an index for rapidly searching directories
   for specific file names, etc.  The four bytes would designate a block where this
   additional information would be found.

o  Internal b+tree node records will be eight bytes long and will consist of
      - The block number of a child block, and
      - The number of 256-byte "pages" of content "to the left"
   It will be possible to do a binary search on such an internal node to find
   the right child to descend to when seeking a particular offset within the
   file.  510 such records will fit in the usable portion of a block.