Eric Auer sent this email to me when I posted the previous announcement about his lbacache hard disk cache. I am reposting it here in its entirety:
Hi, I just read your newsitem about LBAcache: Could you update it or add another item so that people interested in caching floppies and/or not caching hard disks change to the new LBAcache-devel (with floppy support) ? FDDcache is something really ugly - and i13stack is broken in the old lbacache archive, in case anybody has been using it (the bug causes disk errors to be ignored by DOS: As a disk change will be reported as error on the next read/write, one of the biggest problems is that DOS will no longer detect disk changes if i13stack is used in the broken version. As i13stack is only a profiling tool without even a frontend, I hope nobody uses it anyway.
What I am trying to say: If you want to cache floppies, please use the current unstable version LBAcache-devel which contains a real floppy cache. Both the floppy and hard disk cache can be turned on separately. After all, FDDcache has been a horrible kludge... and the i13stack profiler of the old LBAcache version has a severe error with the error reporting, please do not use it.
For the floppy cache and for general curiousity, I would like to know if readahead would be useful (Smartdrv can use N kBytes, defaulting to 16 - the readahead buffer has to be in DOS memory, not in XMS) and if multisector reads make a big difference (the new kernels have it, but LBAcache currently splits the reads up into single sector ones). Both questions apply to hard disks and floppies in different ways... To simulate something related with floppies, you can do:a: undelete syssave fat1 c:nul undelete syssave fat2 c:nul undelete syssave root c:nul
or similar to "warm up" a floppy (the "mirror" to the bit bucket nul will cause the corresponding data to be read into the cache).
And of course I am still pondering the use of write caches: How about smartdrv, does it use unified memory or can you tell it something like "1 MBy of read cache and 64 kBy or write cache" ? What would be a useful size?
Also, Eric writes about this news of UNDELETE and a few other things:
I have some more news on UNDELETE: I do not know how the results of the discussion were, but if there is enough interest, I should probably write an Howto, as the handling is very different from MS/Norton/... undelete. And my version can do "mirror" as well [:-)] .
Next, news about CHKDSK and SCANDISK: It would be great if there was a DOS version of dosfsck by Werner Almesberger. This can find and repair lots of filesystem errors, has a "simulate repair and then chkdsk the simulation" functionality (I guess this means that "create an undo file" would be easy to add) and even an option to UNDELETE a single file given as command line argument. And I have been told that there was something called fsck with very similar functions already on the FreeDOS homepage? Can you give me a link to more documentation on this?
(the FSCK hint was by Dick Sterkenburg, by the way - and the DOSFSCK is what I found on my Linux system on the same issue...)
Hm, what else would be missing? Toms FDEMM seems to work ok now, but my problem is that Tom is no expert on the VM86 monitor and can only improve the other parts of FDEMM substantially. Then, there is VM386, which is an almost complete EMS 4.0 and VCPI 0.90 (claims 1.00) driver/server, but development stopped years ago and lots of bugs remain (I have a clear idea where they should be, but it is a whole lot of code and I think a simpler driver should be better - like FDEMM with EMS 3.2 but no VCPI, which is an important lack). And of course FREEMM386 believes to be getting started yet again, but their goals are still very high and the final version is still -very- far away (as is basically any version of FREEMM386, sorry to have to say that). I often use UMBPCI to have UMB while still having real mode (no VCPI needed, and can run in parallel with an EMS host if EMS is needed), but it is closed source. Probably a DEFRAG utility would be quite nice, but that gives problems with efficient and safe algorithms to both users and creators of such a tool... Some important bugs: There seems to be a library/compiler issue, causing several programs (e.g. find, as far as I remember) not to accept any path component with the arguments. Or it is related to a findfirst/findnext kernel bug, but my kernel is not THAT old. And when I copy a file and get a disk error, the copying cannot be interrupted (if the error is caused by me changing the disk, DOS will treat the new disk as if it was the old one, pretty messy). I do not know if this is a copy or a kernel issue, thus no bugtracking post.