1

I've been given 2k bytes to make a ultra minimalistic file system and I thought about making a stripped out version of FAT16.

My only problem is understanding how do I store the FAT in the volume. Let's say I use 2 bytes per block hence I'd have 1024 blocks. I need a table with 1024 rows and in each row I'll save the next block of a file.

As each of this block can address other 1023 blocks, I fail to see how this table would not use my entire 2k space. I do not understand how to save this table into my hard drive and use only a few bytes rather than just using 1024 block for writing a 1024 row table.

Warren Young
  • 40,875
  • 8
  • 85
  • 101
Cristian Eduardo Lehuede Lyon
  • 1,937
  • 4
  • 22
  • 39
  • 2k indeed seems very low. But 2bytes per block isn't very useful IMHO. Perhaps you should make them 20 times that size (or the closest power of 2). I guess you'll have to cut down on the filename size too? – didierc Feb 15 '15 at 16:43
  • Also, if you can only address 2048 bytes, that's 10bit addressing, but you probably want to keep less than a byte, which means that you need at least a shift of 2 bits, and that's a minimum size of 4bytes per block. With 16 bytes per block, you get a 6 bit address (2bits left for tagging). – didierc Feb 15 '15 at 16:49
  • @didierc True. But my real problem is saving the FAT table to disk. How much disk space is it going to use? That's what I'm failing to understand. – Cristian Eduardo Lehuede Lyon Feb 15 '15 at 16:51
  • I don't know the implementation details of FAT16, I am just thinking about simple block based device considerations. – didierc Feb 15 '15 at 16:55
  • Is the spec 2 kB of *RAM* while the filesystem is running, or 2 kB of code space for the implementation of the filesystem? – Warren Young Feb 15 '15 at 18:07
  • @WarrenYoung I have 2KB of a hard drive. Unlimited RAM. – Cristian Eduardo Lehuede Lyon Feb 15 '15 at 21:22
  • How many files do you need to be able to store? How many characters do we have to allow for the file names? Does it have to be hierarchical, or can you do a flat filesystem? – Warren Young Feb 15 '15 at 22:07
  • @WarrenYoung it can be flat and I can decide how many characters per file. I was thinking around 3 characters per file with a flat directory. – Cristian Eduardo Lehuede Lyon Feb 16 '15 at 12:18

1 Answers1

2

Given that you are allowed to implement a flat filesystem and have such a small space to work with, I would look at something like the Apple DOS 3.3 filesystem rather than a hierarchical filesystem like FAT16. Even the flat filesystem predecessor of FAT16, FAT12, is overly complex for your purposes.

I suggest that you divide your 2 kiB volume up into 256 byte "tracks" with 16 byte "sectors," to use the Apple DOS 3.3 nomenclature. Call them what you like in your own implementation. It just helps you to map the concepts if you reuse the same terms here at the design stage.

You don't need a DOS boot image, and you don't have the seek time of a moving disk drive head to be concerned about, so instead of setting aside tracks 0-2 and putting the VTOC track in the middle of the disk, let's put our VTOC on track 0. The VTOC which contains the free sector bitmap, the location of the first catalog sector, and other things.

If we reserve the entirety of track 0 for the VTOC, we would have 112 of our 16-byte sectors left. Those will pack up into only 14 bytes for the bitmap, which suggests that we really don't need the entirety of track 0 for this.

Let's set aside the first two sectors of track 0 instead, and include track 0 in the free sector bitmap. That causes a certain amount of redundancy, in that we will always have the first two sectors mapped as "used," but it makes the implementation simpler, since there are now no special cases.

Let's split Apple DOS 3.3's VTOC concept into two parts: the Volume Label Sector (VLS) and the volume free sector bitmap (VFSB).

We'll put the VLS on track 0 sector 0.

Let's set aside the first 2-4 bytes of the VLS for a magic number to identify this volume file as belonging to your filesystem. Without this, the only identifying characteristic of your volume files is that they are 2 kiB in size, which means your code could be induced to trash an innocent file that happened to be the same size. You want more insurance against data destruction than that.

The VLS should also name this volume. Apple DOS 3.3 just used a volume number, but maybe we want to use several bytes for an ASCII name instead.

The VLS also needs to point to the first catalog sector. We need at least 2 bytes for this. We have 128 tracks, which means we need at least 7 bits. Let's use two bytes: track and sector. This is where you get into the nitty-gritty of design choices. We can now consider moving to 4 kiB volume sizes by defining 256 tracks. Or, maybe at this point we decide that 16-byte sectors are too small, and increase them so we can move beyond 4 kiB later. Let's stick with 16 byte sectors for now, though.

We only need one sector for the VFSB: the 2 kiB volume ÷ 16 bytes per sector = 128 sectors ÷ 8 bits per byte = 16 bytes. But, with the above thoughts in mind, we might consider setting aside a byte in the VLS for the number of VFSB sectors following the VL, to allow for larger volumes.

The Apple DOS 3.3 catalog sector idea should translate pretty much directly over into this new filesystem, except that with only 16 bytes per sector to play with, we can't describe 7 files per sector. We need 2 bytes for the pointer to the next catalog sector, leaving 14 bytes. Each file should have a byte for flags: deleted, read-only, etc. That means we can have either a 13-byte file name for 1 file per catalog sector, or two 6-byte file names for 2 files per catalog sector. We could do 7 single-letter file names, but that's lame. If we go with your 3-character file name idea, that's 3 files per catalog sector after accounting for the flag byte per file, leaving 2 extra bytes to define. I'd go with 1 or 2 files per sector, though.

That's pretty much what you need. The rest is implementation and expansion.

One other idea for expansion: what if we want to use this as a bootable disk medium? Such things usually do need a boot loader, so do we need to move the VLS and VFSB sectors down 1, to leave track 0 sector 0 aside for a boot image? Or, maybe the VLS contains a pointer to the first catalog sector that describes the file containing the boot image instead.

Warren Young
  • 40,875
  • 8
  • 85
  • 101