MDCACHE/Dir_Chunk not effact

[Ka-ga]

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?

[dang]

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?

[drieber]

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?

[ffilz]

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.

[dang]

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.

[drieber]

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?

[ffilz]

You can call fsal_export->up_ops->invalidate and I believe that is synchronous (it just clears bits in the mdcache entry).