Re: removing an ext2fs file forces disk activity

[Thomas Bushnell, BSG]

nisse@lysator.liu.se (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.