On Tue, Nov 06, 2001 at 09:57:07PM +0100, Marcus Brinkmann wrote:
> > I see that storeio have a option "-e" that hide the device. I suppose that
> > using this option cause ext2fs to go through the storeio translator. So in
> > this case I can happily implement caching in storeio (even if we use more CPU).
>
> [...]
>
> > Any suggestion?
>
> If you put it into libstore (not storeio), ext2fs without -e option to
> storeio *and* storeio can benefit from it (if I understand it correctly).
> So why not do that?
Yes, but there is a problem: usually the cache need to be shared to be
efficient, and imho the only way to implement this in a library is using shared
memory and it is a security flaw.
Perhaps it is a false problem, because usually only a translator at a time
uses a storeio. Probably I have to investigate more how storeio/libstore
works... I'm wondering how can I share memory between the storeio process
and the libstore process, or if there is a way to avoid it.
For the cache the idea is to use a fixed block of memory divided in two
parts: tag area and data area. Data area is basicaly an array of disk blocks.
Tag area is an array of struct containing flags about the status of block
(free/used/dirty), ids of blocks and eventually the time of last
modification for implementing a LRU-like algorithm.
I have two or three ideas about how to use the tag area, but in this moment
I'm more interest in how integrate the cache in storeio/libstore.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
