[EMAIL PROTECTED] (Niels Möller) writes: > 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.
This is fine, but here's the problem: If the following sequence of writes comes from the filesystem: write block A write block B write block A you *cannot* in general omit the first write and coalesce them into a single write. Sometimes you can coalesce them, but it depends on exactly what is happening in the filesystem. This problem cannot be solved in the store; it has to be taken care of by the filesystem. > 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. Filesystems have their own pager, because they need more control over what happens than is provided by the store maps. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
