Simplest (practical) file system?

That's absolutely true, you can do that, and from there it's fairly straightforward. But here's what I'm thinking. Let's say you have just a 1.44MB floppy, with a 512 byte sector size. A convenient allocation size might be one sector, because you can easily fit the total number of allocation units (2880) into a 16-bit unsigned integer (that which is used in the file link blocks). That takes about 360 bytes to store on disk, which fits nicely into a single sector as well. So far, so good. But now let's say you go to an 80MB partition with 512 byte sectors. You then have approximately 163,840 allocation units (not discounting any space used for boot and other common structures). That's too many for a 16-bit word, so you decide to make your allocation units four sectors. That means you have 40,960 allocation units, each of which is 2K in size. Your free-space bitmap, then, would be 5,120 bytes, which takes 10 sectors or 3 allocation units to store depending on your implementation choices, but let's just go with the smaller 10-sector size. I'm thinking about two things: first, trying to keep the entire volume bitmap in memory chews up almost 5K of RAM, and that's probably not good for an 8-bit machine, at least, it's not sufficiently memory-efficient, IMO. Second, if you decide then that you'll only deal with one sector of it at a time to save RAM, you may have to read-then-write juggle those ten sectors a lot. If you do a linear search for a free block, it may be that you can rip through the 255-valued bytes quickly, but they have to be in RAM, so you may have to do several reads to find what you want, which saps time.