On 01/09/2017 06:48 PM, Frank Filz wrote: > So in working on my dirent cache chunking, I've hit one thing that needs > some work. > > We can continue to cache LOOKUPs by caching those dirents, but leaving them > out of chunks. If a readdir overlaps, the dirent will be put into the > appropriate chunk. We should do something to manage the quantity, one option > is to have a single chunk that is operated as an LRU list instead of > directory order. If that chunk is full and a new LOOKUP comes in, the oldest > entry would be dropped. The chunk size for this could of course be a > different size.
I suspect we need to separate the directory cache into two parts: a name cache and a readdir cache. The name cache should probably be a strict timed LRU, and the readdir cache should be chunked, but invalidated probably as a whole. > > CREATE is like LOOKUP except we KNOW the entry didn't exist in the directory > before. > > UNLINK is simple, just remove the dirent from its chunk. The chunk now is a > small chunk, but that doesn't really break anything. It might be handy to > keep it in the chunk as a "deleted" item so if it's cookie is used, we don't > have to bypass the cache. Leave it; this removes the deleted entry tree. > > RENAME is tricky. A rename while a client READDIR is in progress can result > in a variety of situations: > > The entry is completely skipped because the entry's new cookie and ordered > position is before the current position in the client's readdir scan, but > the old position was after. > > The entry could be duplicated because the old position was before the scan > and the new position after. I don't think these are a problem, since these can also happen on local filesystems (and are expected). > > There could be no excitement because both positions are either after or > before the current position. > > A rename out of the directory of course is the same as an UNLINK. > > A rename into the directory might or might not be before or after the > current position. Same as a CREATE? > > A complication arises when the new ordered position (and this goes for > LOOKUP also) would place the entry in the middle of a chunk already cached. > In this case, we COULD completely fail to list an entry that was part of a > rename. This is fine, as above. > We probably should invalidate the dirent cache for any mutation other than > an UNLINK (including RENAME out of the directory). Probably. Daniel ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
