Re: removing an ext2fs file forces disk activity

[Niels Möller]

Jon Arney <jarney1@cox.net> writes:

> For instance, a simple LRU cache algorithm implemented in
> 'libstore' might provide a large performance advantage with
> the caveat that it might occasionally lead to disk inconsistencies.

The important thing for this problem is to cache writes, I think.
Caching reads is important too, but it seems to me to be an almost
orthogonal issue.

How hard would it be to create a new store type that basically
implements only a write-cache: It would have store_write put the
modified block into a queue, from which blocks are written to the
underlying store later by a separate syncing thread. store_read would
have to check this queue for blocks that are modified but not yet
written to disk, but would otherwise just pass the read on to the
underlying store.

I'm a little confused about the interface between the filesystem and
its store, I remember the talk about filesystems using mmap, but when
I grep through the source for ext2fs and libdiskfs, I find some uses
of store_read and store_write in ext2fs/pager.c, and no references at
all to store_map. Actually, greping the entire hurd source for
store_map, I can find only one single function that sues it:
storeio/pager.c:dev_get_memory_object.

If in fact store_read and store_write, not store_map, is the interface
that is used, that should make caching a little easier.

Where are the rpc:s defined that are used by stores and pagers? I
would have expected som hurd/store.defs and hurd/pager.defs, but I'm
not very familiar with the hurd sources.

Regards,
/Niels