New devel release of LBACACHE now online

Hi, I am pleased to announce LBAcache devel 10nov02.

The new version still uses about 4k of DOS RAM for its code, the binary is
roughly 8k now (both .sys and .com version available). All written in NASM
style assembly language. You need at least a 386 CPU and enough XMS free.

LBAcache is a disk cache: It stores data that you have recently read from
disk (or written to disk) in XMS RAM, and when you later read it again, you
can use the copy in RAM and save the time needed for another disk access.

LBAcache does NOT delay or pool writes: Writing to disk will NOT become
faster with LBAcache in general. However, on the good side, you do not need
to take care that you wait until your data is written back, as the writes
are always at once.

You can cache harddisks, with or without LBA support, whatever you prefer to
use. You can also cache floppies. LBAcache tries to forget previously read
data when it detects a disk change (important). However, LBAcache will
NOT act correctly when you use floppy disks of mixed size in the same
drive - it will trash data copied to/from that floppy then!!!

Improvements in the new development (unstable) version:
- In addition to the 4k of code, now only 2k of DOS memory per 1 MB of XMS
  memory cache are needed (old version: 4k). This is because I have made
  the element size 4k (was 2k). By the way, MS DOS SMARTDRV can have 1k..8k
  and defaults to 8k. I am not sure if too big element sizes decrease the
  performance. I think 4k is a good size.
- You can now give the size in multiples of 1/4 MB, at maximum 99 of them.
  There are other reasons for a 32 MB size limit as well, so I think the
  new practical limit of 25 MB should be okay :-). Old limit was 4.5 MB...
  Remember, you can install several instances (not more than one per drive)
  if you want even bigger caches.
- I still recommend using the STAK option. FreeDOS has a quite small kernel
  stack and you may suffer crashes without enabling STAK (enabling STAK
  tells LBAcache to allocate its own private stack).
- LBAcache now detects and caches up to EIGHT harddisks. There were actually
  people asking for this feature. You can, by the way, chose wheter you call

  the primary slave harddisk (0x81) "D" or "1" on the command line. Just for
  those who want to avoid confusing the physical harddisk number with a,
  possibly unrelated, drive letter.
- LBAcache now checks the "geometric sanity" and the ability to handle LBA
  accesses PER DISK. For the very rare cases where you have one disk that
  is completely unable to do LBA in an otherwise LBA capable system.
- Floppy size detection on STARTUP has been improved. However, size CHANGES
  are still not detected properly! If you dare, you can try if LBAcache now
  caches, for example, 1.2 MB disks in 1.2 MB drives and 360k disks in 360k
  drives properly. Please tell me about your results.

Old news:
You can run all modes from all versions: You can use lbacache.sys to
display statistics (now human-readable) and you can use lbacache.com to
install the cache. A limitation is that you cannot free the allocated DOS
RAM (only the XMS RAM) by uninstalling a lbacache.sys instance.
You if you think LBAcache has messed things up and did not notice a disk
change, you can run LBACACHE SYNC to make it forget the buffered data.
LBAcache will shut itself down or at least SYNC when it feels a critical
problem.
You can use LBAcache on any type of partition, as long as the disk BIOS
is involved.
You cannot yet use it with changeable harddisks (can DOS handle them?),
at least you cannot change the medium while LBAcache is caching it. If
you exchange it with a medium of the same size, things are very likely
to work fine, but I cannot test this.

This is a development version. I have tested it a bit and it seems to
work, but there may be bugs left. Please use it for some task that uses
the disk a lot but where you can live with a crash or trashed data, just
in case. I do not BELIEVE there are such bugs in it, but without people
to test LBAcache under various conditions, I simply cannot know for sure.

Maybe you want to use the new version of my UNDELETE toolkit to backup
at least some metadata (mirror, for the paranoid ones also mirrtree).
However, I do NOT expect that LBAcache has serious bugs. Just the usual
disclaimer for driver software...

Example use:
devicehigh=lbacache.sys buf 42 drv df flop stak
will cache drive 0x81, 0x83 ("D, F"), all floppy drives that have
disk change detection, and enables the local stack.
loadhigh lbacache.com buf 80 stak
will cache all harddisks, no floppies, and allocate 20 MB of XMS
lbacache stop
will remove all instances of lbacache from memory as far as possible.
lbacache info
will show statistics (both technical and human readable) of all currently
active lbacache instances

When you give a size of "0", you will get the "easter egg size". This was
256k in old versions and is 33M in the current version ;-). Apart from
this, size must be 1..99 * 256k (old version: 1..9 * 512k). Default size
is still 2M, but this may change in the future.


Whatever. Read the docs and test yourself. The .zip is now in FreeDOS
directory structure for easier installation (as are the zips of all
other programs that I have updated or released in the past days). Get it at:

http://www.coli.uni-sb.de/~eric/stuff/soft/ -> lbacache-10nov02.zip


I hope to get more happy feedback than bugreports :-).

PS: Benchmarks wanted: Compared to smartdrv /x or nwcache (with delayed
writing turned off), how does it perform, at various sizes of XMS ? Does
the new version perform differently from the old, smaller element size
version? Do you believe a readahead buffer would make a difference? For
smartdrv, it defaults to 16k, eats 16k of your precious DOS RAM, and can
be set to 0..64k as far as I know.


Happy caching! Eric.