Daire Byrne <Daire.Byrne@xxxxxxxxxxxxxx> wrote:
> This would be really cool for the VPN/homedir application. I have found that
> trying to run your homedir over a VPN results in very slow application load
> times simply because when searching PATHs (e.g. Maya, Python etc.) apps will
> make many many open() calls most of which simply return ENOENT (No such
> file or directory). If we could cache the entries of the dir subsequent file
> lookups would not need to go to the network.
Caching negative results would certainly be possible, provided you can
determine that the directory has been updated when a previously negative entry
has been instantiated. This can probably be done reasonably by checking the
mtime and ctime on the dir.
> There are even more access() calls to non-existent files than open() calls
> which really slows things down a lot. Does it make sense to cache the perms
> of files in a dir too?
Ummm... As I said above, negative results due to non-existence should be
reasonably easy. We do this with the dentry cache after all.
However, negative results due to permissions failure is harder to deal with. I
don't know that NFS4 will notify you if the annotations on a file change,
though you can poll the ctime. Also, this depends on local factors, such as
the callers credentials, and so you can have several results for a single file.
We could certainly cache the mode/ACL of a file and attempt to make the check
locally - indeed this would be required for disconnected operation - but the
final authority still has to be the server.
> That's good to know. I thought READDIRPLUS was a standard NFSv3 feature? It's
> funny how after all this time AFS still has some pretty cool and unique
> features.
I'm not entirely certain whether READDIRPLUS is mandatory for NFS3 and 4. It's
not available on NFS2, however.
> Sorry, I wasn't very clear. I'm interested in testing the NFS cache when we
> have a single common QCOW2 disk image accessed by many (100+) clients but all
> writes simply go back to a separate QCOW2 images (which QCOW2 supports). I
> suppose this is the VM equivalent of caching a "diskless" network boot Linux
> distro except the image is a single file instead of many files. Again knowing
> that the read-only master image never changes it would be good if one went to
> the cache before doing any network lookups. We *could* just copy the entire
> image locally to the machine each time but obviously getting cachefilesd to
> manage it automatically is more elegant. The performance may be worse though
> if the PAGEs get written randomly out of order in the corresponding local
> cache file.
Is this what you're thinking of:
(1) A base image for a virtual disk is made available on an NFS server.
(2) When clients want to read pages, they check fscache, and if that doesn't
have a copy of the page, the page is fetched from the server. If fscache
does have a copy, it's fetched from there.
(3) When a client alters a page, that alteration is stored to fscache only; it
is not sent back to the server. Future retrievals of the page will then
obtain it from fscache, and not the server.
David
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cachefs
