The filesystem on the server is pretty much irrelevant as long as (a) it
doesn't change, and (b) all the data is in memory on the server anyway.
The way the client works is like this:
+---------+
| |
| NFS |--+
| | |
+---------+ | +----------+
| | |
+---------+ +-->| |
| | | |
| AFS |----->| FS-Cache |
| | | |--+
+---------+ +-->| | |
| | | | +--------------+ +--------------+
+---------+ | +----------+ | | | | |
| | | +-->| CacheFiles |-->| Ext3 |
| ISOFS |--+ | /var/cache | | /dev/sda6 |
| | +--------------+ +--------------+
+---------+
(1) NFS, say, asks FS-Cache to store/retrieve data for it;
(2) FS-Cache asks the cache backend, in this case CacheFiles to honour the
operation;
(3) CacheFiles 'opens' a file in a mounted filesystem, say Ext3, and does read
and write operations of a sort on it;
(4) Ext3 decides how the cache data is laid out on disk - CacheFiles just
attempts to use one sparse file per netfs inode.
What are you trying to do exactly? Are you actually playing with it, or just
looking at the numbers I've produced?
These are difficult questions to answer. The obvious answer to both is "it
depends", and the real answer to both is "it's a compromise".
Inserting a cache adds overhead: you have to look in the cache to see if your
objects are mirrored there, and then you have to look in the cache to see if
the data you want is stored there; and then you might have to go to the server
anyway and then schedule a copy to be stored in the cache.
The characteristics of this type of cache depend on a number of things: the
filesystem backing it being the most obvious variable, but also how fragmented
it is and the properties of the disk drive or drives it is on.
Whether it's worth having a cache depend on the characteristics of the network
versus the characteristics of the cache. Latency of the cache vs latency of
the network, for example. Network loading is another: having a cache on each
of several clients sharing a server can reduce network traffic by avoiding the
read requests to the server. NFS has a characteristic that it keeps spamming
the server with file status requests, so even if you take the read requests out
of the load, an NFS client still generates quite a lot of network traffic to
the server - but the reduction is still useful.
The metadata problem is quite a tricky one since it increases with the number
of files you're dealing with. As things stand in my patches, when NFS, for
example, wants to access a new inode, it first has to go to the server to
lookup the NFS file handle, and only then can it go to the cache to find out if
there's a matching object in the case. Worse, the cache must then perform
several synchronous disk bound metadata operations before it can be possible to
read from the cache. Worse still, this means that a read on the network file
cannot proceed until (a) we've been to the server *plus* (b) we've been to the
disk.
The reason my client going to my server is so quick is that the server has the
dcache and the pagecache preloaded, so that across-network lookup operations
are really, really quick, as compared to the synchronous slogging of the local
disk to find the cache object.
I can probably improve this a little by pre-loading the subindex directories
(hash tables) that I use to reduce the directory size in the cache, but I don't
know by how much.
Anyway, to answer your questions:
(1) It may help with heavily loaded networks with lots of read-only traffic.
(2) It may help with slow connections (like doing NFS between the UK and
Australia).
(3) It could be used to do offline/disconnected operation.
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
