Simplest (practical) file system?

On Sun, 27 Jul 2003, Bob Shannon wrote: What size drive? You might want something different for an 80G drive than for a 100K floppy I thought that you said that you wanted PRACTICAL 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.