Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:Is it a problem because, if there are multiple copies of the same remote file
in its cache, then FS-cache doesn't know, upon reconnection, which item to
match against a particular remote file?
There are multiple copies of the same remote file that are described by the
same remote parameters. Same IP address, same port, same NFS version, same
FSID, same FH. The difference may be a local connection parameter.
An adequate first pass at FS-cache can be done without guaranteeing
persistence.
True. But it's not particularly interesting to me in such a case.
There are a host of other issues that need exposure -- steady-state
performance;
Meaning what?
I have been measuring the performance improvement and degradation numbers, and
I can say that if you've one client and one server, the server has all the
files in memory, and there's gigabit ethernet between them, an on- disk cache
really doesn't help.
Basically, the consideration of whether to use a cache is a compromise between
a host of factors.
cache garbage collection
Done.
and reclamation;
Done.
cache item aliasing;
Partly done.
whether all files on a mount point should be cached on disk, or some in
memory and some on disk;
I've thought about that, but no-one seems particularly interested in
discussing it.
And what would it harm if FS-cache decides that certain items in its cache
have become ambiguous or otherwise unusable after a reconnection event, thus
it reclaims them instead of re-using them?
It depends.
At some point I'd like to make disconnected operation possible, and that means
storing data to be written back in the cache. You can't necessarily just
chuck that away.
I can't just say: "Well, it'll oops if you configure your NFS shares like
that,
so don't. It's not worth me implementing round it.".
What causes that instability? Why can't you insulate against the instability
but allow cache incoherence and aliased cache items?
Insulate how? The only way to do that is to add something to the cache key
that says that these two otherwise identical items are actually diffent
things.
I'm arguing that cache coherence isn't supported by the NFS protocol, so how
can FS-cache *require* a facility to support persistent local caching that
the protocol doesn't have in the first place?
NFS has just enough to just about support a persistent local cache for
unmodified files. It has unique file keys per server, and it has a (limited)
amount of coherency data per file. That's not really the problem.
The problem is that the client can create loads of different views of a remote
export and the kernel treats them as if they're views of different remote
exports. These views do not necessarily have *anything* to distinguish them
at all (nosharecache option).
Now, for the case of cached clients, we can enforce a reduction of incoherency
by requiring one remote inode maps to a single client inode if that inode is
going to be placed in the persistent cache.
Invalidating is cheap for in-memory caches. Frequent invalidation is going
to be expensive for FS-cache, since it requires some disk I/O (and perhaps
even file truncation).
So what? That's one of the compromises you have to make if you want an
on-disk cache. The invalidation is asynchronous anyway.