Hi Tom, thanks for your feedback :-)
> > 2. It is way slower in file "copy/compare" than other DOSes. > > (maybe we should make FAT and DIR data access smarter?) ... > FreeDOS allocates always the lowest unused cluster, even if > the file should be enlarged by a large ( > 1 cluster) amount. ... which also means more fragmentation ... I think we agree that it would help to remember the location of the first free / last allocated cluster. FAT32 even has a special nfreeclst field for that... One could make read/write_fsinfo work for all FAT types by storing the info in RAM for non-FAT32 drives. This would affect fatfs.c and fattab.c ... Can you explain how find_fat_free decides where to start searching? It might also make a difference to limit how often the FAT32 fsinfo sector is written to disk - depends on how BUFFERS and priorities are processed, you can probably estimate the performance better than I here. > search for a bunch of clusters that are able to fit this request > could accelerate this I think I prefer searching a cluster at a time but in a linear fashion, using a "next free cluster" pointer instead of searching from the start of the FAT each time you need one more cluster. If that is easier, you could start by only implementing it for FAT32, then users can already start doing experiments / compare the FAT32 performance to FAT16 performance :-). > b) COMPARE > if enough (small) files in large enough directories with enough > directory depth are compared, it might matter that fastopen isn't > implemented. Anybody ? Hmmm well I agree that FASTOPEN can be useful in other ways than a cache, but does any MSDOS version have a kernel built-in FASTOPEN? I thought they dropped all FASTOPEN around DOS 5 because they thought that a generic disk cache would be enough? Does FreeDOS for example remember the starting cluster of the current directory and / or a directory which is "being findnext-ed" at the moment? > > - you can say "BUFFERS=-5" if you want "5 and not more than 5" > > (as opposed to "BUFFERS=5" which is "at least 5" in FreeDOS) > > - HMA allocation (int 2f.4a0n) in FreeDOS should allow apps (such > > as Jack's drivers) to use the free HMA space... > yes and no; see www.bttr-software.de/forum/forum_entry.php?id=867 Ah interesting... user allocation is only possible after all DEVICEs are loaded because only then buffers are moved to HMA? Yet BUFFERS and FILES are processed before DEVICE afair, and FreeDOS starts using the HMA for the kernel code as early as possible afair (right after the DEVICE=HIMEM line) so... Are there good reasons to delay HMA buffer / fnode allocations? Anyway. An obvious solution would be to DEVLOAD the UDMA / UDVD drivers to let them enjoy "userspace" allocation of HMA space. Could anybody test that? :-) Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
