Hi!
MS-DOS 4.0 is online, MIT license, and there is this technical doc:
https://github.com/microsoft/MS-DOS/blob/2d04cacc5322951f187bb17e017c12920ac8ebe2/v4.0/src/CMD/FASTOPEN/FASTOPEN.TXT
As you can see, the MS-DOS implementation uses some internal hooks
between kernel and FASTOPEN. The latter is a cache for finding
files and directories without having to process too much metadata
from the filesystem on disk for each access.
In a way, it is a directory entry cache. However, to save RAM,
each record contains only: 4 dw for LRU, child, sibling, MRU
and 22+5 bytes of directory data: name, attrib, time, date,
cluster, filesize + location of the dirent on disk, I think?
Now FreeDOS has dirent with more content: dir_case, dir_crtimems,
dir_crtime, dir_crdate, dir_accdate are known and clusters can
be 32-bit (28-bit) instead of 16-bit values for FAT32 drives.
FreeDOS also has some LFN awareness, although full support can
require loading separate drivers. See our fat.h for details.
Another FreeDOS specific thing are F-Nodes, related to SFT items.
They are mostly used in fatfs.c and fatdir.c and a bit by lfnapi.c
At the moment, FreeDOS only has a global array of TWO fnodes and
I think it was on the way towards getting rid of those as well
at some point long ago? Last mention in history.txt was 2009, so
there were no later changes related to fnodes in the changelog.
As one can see in fnode.h, the contents of an FNODE are:
flags, a dmatch directory match pointer, location of the dirent
on disk (sounds familiar!) as well as the full dirent itself,
a pointer to the block device DPB, SFT index and byte and
cluster offsets within the file/... as well as absolute cluster.
There also is a definition of lfn_inode in fnode.h: LFN stuff.
So in a way, FNODES are FAT32 aware and FAT extension (extra
timestamps etc.) aware instances of exactly the type of data
that FASTOPEN would cache!
Which makes me wonder whether FreeDOS could improve speed and
reduce disk access by having some FNODE CACHE, either inside
the kernel or as loadable FreeDOS-specific add on?
Given that we usually have some free space in the HMA and
FNODES are less than 64 bytes in size, KERNEL INTERNAL FNODE
CACHING may be a good choice. While MS-DOS mentions 8 bytes
of cache metadata (LRU, MRU, sibling and child) in FASTOPEN,
we could even work with less metadata per cache entry :-)
FASTOPEN defaults to just 34 cache entries per cached drive,
with a range from 10 to 999 per drive and in total. It uses
short LRU / MRU chains, one for each drive. Because you have
to walk the tree to the dirent in question, you end up caching
the frequently used dirent as well as ALL of their parents.
Given that FreeDOS tends to be used on faster CPU and given
that it always is EVIL to process entire SECTORS or clusters
of metadata, even with a disk cache, I would assume that you
already get a GOOD effect with a total cache size of < 256
FNODES and a more simple algorithm :-) For example, just check
the DPB to know which FNODES are for "your" drive and use ONE
global LRU chain: 64 bytes per cache-FNODE should be enough :-)
What do you think?
Cheers, Eric
PS: Happy holidays to everybody!
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel