Hi Kevin,
>And thus likely inefficient. If you didn't have to sit down
>and think for a while on how to squeeze every drop of performance
>out of the cache, then I'm guessing its not optimal.
I was afraid I would get this reaction because of
the efforts to avoid C++ pointer indirections I spotted in Bochs.
However, the STL map is very efficient, space efficiency is
O(n), search efficiency is O(log n). I can remove the
STL btree implementation and write my own, but you or I
can not make it measurable faster in this context.
I'm afraid this is a bit of a religious issue, C versus C++,
vi versus emacs.
We are dealing with file-io here which is inherently
inefficient. I'm aware of especially the code-size problems
with C++ templates, but I think the use of C++ is valid for the cache.
If it remains unacceptable for you, then it should be rewritten.
Anyway, i finished the full implementation.
It has full support for 64bit addressable files and a persistant cache.
I was able to access and boot my full /dev/hda
There are two usefull cache modes: mode=user and mode=never
In mode "user" the user flushes the cache by hitting the GUI button,
in mode "never" the cache is never flushed to the disk image.
The option persistfile=/xxx/cachefile
adds a persistant cache file. This means that the original diskimage
is always left untouched, but the changes remain available in the cache.
plugin = ./plugins/write-cache/write-cache.so mode=never
persistfile=/home/tom/plexcache
#plugin = ./plugins/write-cache/write-cache.so mode=user
persistfile=/home/tom/plexcache
I had to edit harddrv.cc and harddrv.h and ofcourse write-cache.cc.
I'll attach the files, hope you'll use them as they are, otherwise if
you have
a good btree search in C, I'll rewrite it :-/
Bye
Tom
write-cache.cc
harddrv.cc
harddrv.h
