Simplest (practical) file system?

From: Bob Shannon <bshannon_at_tiac.net>
Date: Sun Jul 27 15:53:00 2003

Fred Cisin wrote:


<snip>

>>How did some of the very early DOS systems allocate disk space in the
>>days before FAT tables, etc?
>>
>
>I thought that you said that you wanted PRACTICAL
>

Yes, practical, like RT-11 was (is).

Remember this is a file system for vintage hardware (well, including
vintage hardware with a ATA disk hack).

>>Just how simply can this be done?
>>
>
>It is unusual for somebody to set out to write a file system who isn't
>already familiar with what's been done before. (some say that UCSD P
>system was the last time that one was written by people who had no idea
>what they were doing)
>
Its unusual for anyone to try to write a file system without a lot of
modern fluff added too.

>
>Do you WANT it to be compatible with anything else?
>If NOT, then you will also have to write conversion software. Maybe not
>now, but someday.
>
Actually, in this case, we already have ways to exchange data with
conventional machines. We can support
a vintage HP CPU hung off a serial port, as a parasite to a PC host
machine, or a stand-alone system that
cold boots from its own disk drive for HP's in collections with working
peripherals.

>
>Greatest compatibility would be to implement the MS-DOS structure. To
>make it simple, you can wait and add sub-directory support later (like MS
>did with 2.00)
>
>
>But if you want to roll your own from scratch, . . .
>Your drive head will spend more time in the DIRectory than anywhere else.
>(Yes, it could be cached in RAM, but remember the fiasco that resulted in
>having to release MS-DOS 6.2x!)
>
>Does your drive have a track 0 switch? If so, then that's where you
>oughta put the DIRectory. (CP/M (after reserved track(s)), MS-DOS, MAC
>400/800K, etc.) If not, then consider mid-disk. (TRS-DOS, Coco, MS
>Stand-alone BASIC (NEC-DOS, etc.), OS/2 HPFS, etc.)
>Putting the DIRectory at the beginning of the usable space simplifies a
>few things.
>
Not an option for actual HP hardware. HP's cold-boot roms load an
intermediate loader program from
track 0, and this intermediate loader (like MS-DOS's) then loads the O/S
into memory. So to be compatible
with HP's cold boot mechanisim track 0 holds the start of the intrim loader.

>
>Decide how large an allocation unit you want. Large ones make for fewer
>to keep track of, with possible performance benefits, but wast more space
>if you use a lot of tiny files. You COULD use blocks that are SMALLER
>than a sector (128 bytes, ...); but you said simple.
>
Right, because of the way HP21MX machines page VM, and all HP1000's see
memory, we are allocating
units of 1024 16-bit words. In fact, the ATA disk controller reads,
writes, and addresses its 8 gb disk as an
array of 1024 16-bit words.

>
>Decide the DIR structure.
>Fixed size for each FPDE (File Primary Directory Entry) avoids some
>unnecessary hassles.
>
Yep, probably 32K words, given the vintage of the machines and their
maximum logical memory capacity.

>
>Filenames shorter than 8.3 are too short.
>Long filenames make for a much more complex DIR structure.
>
Yep, we are also placing file pointers for each file in the directory
entry, so we can 'reopen' files from their
last point of access, or 'open' them from the start. One of the reasons
behind this hack is that we are limited
to only 2 file buffers in memory (unless the file system becamse HP 21MX
specific). We plan to keep this
open to the 2116 and 2100A/S machines as well.

>
>(NOTE: Windoze does NOT have long filenames. It has 8.3 filenames, PLUS a
>file can also have a "nickname" that is NOT stored in that file's FPDE
>(MS stores the nicknames in the space that would otherwise have held
>FPDEs, but does NOT store it as an FPDE))
>
>
>UCSD P system stores starting and ending block numbers, and can not have a
>non-contiguous file.
>
This is actually a feature for HP machines. Some disk systems MUST use
DMA transfers, and DMA transfers
to and from the disk must be made to linear disk blocks. Nonlinear
files add a lot of complexity.

>
>CP/M stores a list of block numbers, and when that overflows the space
>provided in the FPDE, an additional directory enty is needed for the file.
>
So CP/M files are non-linear? Or can be non-linear? Then again, the
BDOS is like 6K, right?

>
>TRS-DOS stores a short list of starting points plus length for each
>starting point.
>
>Apple-DOS stores starting point, and then each file contains IN THE FILE'S
>SPACE, pointers to the next space. Thus forming a linked list of sectors,
>but giving you 254? bytes of data in each 256 byte sector.
>
>MS Stand-Alone BASIC, MS-DOS, and MAC 400K/800K use a linked list of block
>numbers stored in a separate section of the DIR.
>(MAC 400k/800k uses the same structure as MS-DOS, with just enough changes
>to not be interchangeable. (serious shortage of systems programmers in
>those days))
>
>
>If you want full functionality, then nothing is going to be significantly
>less work to implement than MS-DOS, which would give you disk
>interchangeability.
>
Define full functionality?

RT-11 works just fine, and it does not have the level of 'fluff' found
in many modern file systems.
Received on Sun Jul 27 2003 - 15:53:00 BST