[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: removing an ext2fs file forces disk activity

From: Thomas Bushnell, BSG
Subject: Re: removing an ext2fs file forces disk activity
Date: 25 Mar 2002 13:36:20 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]