You still need a database to manage the cache. A filesystem such as Ext3
makes a very handy database for four reasons:
(1) It exists and works.
(2) It has a well defined interface within the kernel.
(3) I can place my cache on, say, my root partition on my laptop. I don't
have to dedicate a partition to the cache.
(4) Userspace cache management tools (such as cachefilesd) have an already
existing interface to use: rmdir, unlink, open, getdents, etc..
I do have a cache-on-blockdev thing, but it's basically a wandering tree
filesystem inside. It is, or was, much faster than ext3 on a clean cache, but
it degrades horribly over time because my free space reclamation sucks - it
gradually randomises the block allocation sequence over time.
So, what would you suggest instead of a backing filesystem?
What do you mean? I'm not doing it like Sun. The cache is a side path from
the netfs. It should be transparent to the user, the VFS and the server.
The only place it might not be transparent is that you might to have to
instruct the netfs mount to use the cache. I'd prefer to do it some other way
than passing parameters to mount, though, as (1) this causes fun with NIS
distributed automounter maps, and (2) people are asking for a finer grain of
control than per-mountpoint. Unfortunately, I can't seem to find a way to do
it that's acceptable to Al.
I don't think there's much I can do about NFS. It requires the filesystem
from which the NFS server is dealing to have inode uniquifiers, which are then
incorporated into the file handle. I don't think the NFS protocol itself
needs to change to support this.
No, but there aren't many. CacheFiles doesn't actually do very much, and it's
hard to reduce that not very much. The most obvious thing is to prepopulate
the dcache, but that's at the expense of memory usage.
Actually, if I cache the name => FH mapping I used last time, I can make a
start on looking up in the cache whilst simultaneously accessing the server.
If what's on the server has changed, I can ditch the speculative cache lookup
I was making and start a new cache lookup.
However, storing directory entries has penalties of its own, though it'll be
necesary if we want to do disconnected operation.
cachefilesd runs in userspace. It's possible it isn't doing enough to preload
all the metadata.
That's a per-netfs thing. With the test rig I've got, it's going to the
on-disk cache that's the killer. Going over the network is much faster.
See the results I posted. For the tarball load, and using Ext3 to back the
cache:
Cold NFS cache, no disk cache: 0m22.734s
Warm on-disk cache, cold pagecaches: 1m54.350s
The problem is reading using tar is a worst case workload for this. Everything
it does is pretty much completely synchronous.
One thing that might help is if things like tar and find can be made to use
fadvise() on directories to hint to the filesystem (NFS, AFS, whatever) that
it's going to access every file in those directories.
Certainly AFS could make use of that: the directory is read as a file, and the
netfs then parses the file to get a list of vnode IDs that that directory
points to. It could then do bulk status fetch operations to instantiate the
inodes 50 at a time.
I don't know whether NFS could use it. Someone like Trond or SteveD or Chuck
would have to answer that.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
