Simplest (practical) file system?

From: Fred Cisin <cisin_at_xenosoft.com>
Date: Sun Jul 27 14:53:00 2003

On Sun, 27 Jul 2003, Bob Shannon wrote:
> What is the simplest usable disk file system to implement?
> More specifically, if your going to write a disk file system from
> scratch, what would be the easiest way to implement
> some basic file system functionality?

What size drive? You might want something different for an 80G drive than
for a 100K floppy

> 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

> 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)


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.

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.

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.

Decide the DIR structure.
Fixed size for each FPDE (File Primary Directory Entry) avoids some
unnecessary hassles.
Filenames shorter than 8.3 are too short.
Long filenames make for a much more complex DIR structure.
(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.

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.

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.
Received on Sun Jul 27 2003 - 14:53:00 BST