From: Pasi Ojala (albert_at_cs.tut.fi)
Date: 2007-08-29 14:47:21
> I do have experience implementing FAT12/FAT16 on the CBM, although
> it's been a while.
I have implemented read-only handling of FAT/FAT32 (partial FAT12 support).
I has been highly optimized for code size.
> IIRC caching FAT is essential for a good performance.
My approach is the create a fragment list/table that remembers the
starting sectors and number of sector pairs for the opened file.
At this point the FAT (file allocation table) sectors need to be read.
Normally this table has only one entry, because files are quite
seldom fragmented. Surprisingly, directories (that are actually
files in FAT, except the FAT12/16 root directory) are more often
fragmented, because only one cluster is allocated when more space
is needed in a directory.
The great thing about the fragment list/table is that the generation
routines can be used for both files and directories, and you can also
process nested directories with it by starting to fill it at a
different point.
For FAT12/FAT16 the fragment list of the root directory is just
filled according to the root block info.
FAT12 is only partially supported because of the code space issue we
have had: no subdirectories are allowed, and files are assumed to be
unfragmented. For an octet-oriented system supporting also FAT12 should
be easier.
> Caching data
> blocks as well, but it depends on the access pattern. For a sequential
> write you need to cache the (means make a write-back cache) block,
It depends on the application. In systems where you can only have one
file open at a time, you only need one sector for both reading and writing.
For two files you may get by by two buffers, but more is better.. :-)
-Pasi
--
/'And give him 10000 crowns to do whatever he wants.' This was a fortune.
And I didn't even know why I had done this. This pain will pass, I thought,
it has to. And I must gain some control over my thoughts, realize these
things cannot affect me./ -- Lestat in "The Vampire Lestat"
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.