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.