Jon Arney <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
