I have a question, does anyone use Trust_Readdir_Negative_Cache = true in their EXPORT config?
It's actually only compatible with the old unchunked dirent cache since with chunks we never guarantee we have all the dirents in cache, there is no way to serve negative lookup just based on the cache (we can still serve negative lookup for entries recently removed via Ganesha since we have a dirent that has been marked deleted in that case). I am looking at how the DIR_POPULATED flag is used since it will never be set by uncached mode or chunking, my hope is to repurpose the flag to indicate when we can serve a readdir from the dirent cache chunks, which resolves out of the situation that if we have some chunks cached and then we get a lookup or create that we can't add to a chunk (which is true for all FSALs other than RGW, and for RGW only if the new dirent happens to be within a chunk), then we need to invalidate the chunks (except...) So here was my original idea for what kinds of invalidation we do on directories, look for a new idea below: If we get a create or lookup that adds a new dirent to the directory, and we can't add it to a chunk, then we must invalidate any chunks. Any create or delete (including rename) must invalidate the directory attributes If we refresh attributes, and it shows and mtime or change attribute change we must invalidate the directory (note - this makes retention of the dirent cache after a delete a short lived thing, the first thing that refreshes attributes should see a directory change and flush the dirent cache since we can't know if the directory changed for other reasons). Specifically create and lookup will not invalidate loose dirents (those that don't belong to a chunk), however, such a change will mark the chunks as invalid. They may be used to serve lookups, but if the chunks are marked invalid and a readdir request comes in, the chunks will be invalidated at that time. Now a special case... For FSALs that CAN support adding dirents to chunks, if a lookup or create can't be added to a chunk, we actually CAN retain the chunks we have, we know the new dirent is in another chunk. Even if the case happened to be that we had chunks from the middle of the directory, and the new file happened to be before the first chunk (which we actually happen to know also...), a new readdir that starts at the beginning of the directory will populate chunks at the beginning and will eventually collide with the chunks cached from before, which is a condition we handle, and all will be well. Now on the flip side, we COULD serve negative lookups on such FSALs because if the entry was determined to be within a chunk we have cached, we know it doesn't exist (subject to the coherence of our cache - hopefully closely coherent due to upcall invalidation). Anyway, need folks thoughts on all of this because the current code too aggressively invalidates the dirent cache to the point that actually loose dirents aren't actually cached even though we go to all the work of caching them (the dirent cache gets invalidated just after they are added). Thanks Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
