nfs-ganesha
nfs-ganesha copied to clipboard
MDCACHE/Dir_Chunk not effact
ganesha config /etc/ganesha/ganesha.conf set disable entries but ls get null
MDCACHE {
Dir_Chunk = 0;
}
version:
Alternatively, how can one directly invoke FSAL without the necessity for caching?
In general, we don't recommend ever setting dir_chunk to 0. It invokes an entirely different codepath that isn't as well tested. What is the reason that you don't want to have dirent caching?
I have a related question. My custom ganesha/FSAL is configured to run with Dir_Chunk=0. We implement a virtual filesystem, so sometimes dirents change behind the scenes. If I run with the default Dir_Chunk setting, will that cause caching problems when a dirent is added/removed behind the scenes? How should I deal with that situation?
When the directory attributes have expired, and a directory listing is needed, MDCACHE will issue a new readdir and re-populate the dirents. We don't try to dynamically keep the dirents valid unless the FSAL supports compute_readdir_cookie which allows MDCACHE to place entries created by create, rename, or lookup.
This is solved by sending an INVALIDATE UP call (see src/include/fsal_up.h) on the directory. This will invalidate the dirent chunk cache for that directory, and future calls will reload the cache.
In general, any change to a filesystem not through Ganesha should result in an UP call.
I see fsal_up_vector has an invalidate function pointer. There is also up_async_invalidate.
My custom FSAL creates a background thread of its own, this thread communicates with remote servers using our protocol. Can I issue a synchronous INVALIDATE UP request from this thread? Alternatively, can I issue an asynchronous INVALIDATE UP request from this thread and somehow block for its completion? Which function do I need to call?
You can call fsal_export->up_ops->invalidate and I believe that is synchronous (it just clears bits in the mdcache entry).
You want the synchronous invalidate call, I believe.
Closing for being inactive for more than 60 days.
Please re-open if you have more questions.