Simplest (practical) file system?

From: Dwight K. Elvey <dwightk.elvey_at_amd.com>
Date: Mon Jul 28 14:41:00 2003

>From: Joe <rigdonj_at_cfl.rr.com>
>
>At 11:18 AM 7/28/03 -0700, Patrick wrote:
>>> > I agree that it's simple, but not that it's efficient. For small micros,
>>> > finding the first "0" bit in an arbitrarily long bit string takes a few
>>> > cycles.
>>>
>>> You would just look for the first byte that is not a 255.
>>
>>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.
>
>
> I wonder if it really would sap a lot of time. Modern IDE drives have
>large cache buffers so I would think that system could very likely read the
>data from the buffer. I'm thinking that as slow as these old systems are
>and as fast as the modern drives are that it would be better to use a
>simple and fast algorithim even if it means more drive accesses.
>
> Joe
>

As I recall, Bob is looking to put this onto some old HP hardware.
Dwight
Received on Mon Jul 28 2003 - 14:41:00 BST