Re: [Nfs-ganesha-devel] Work in Progress Readdir Chunking Posted
> > Another thought is to look at the nlinks in the directory and decide > > to cache or chunk. > > Please do not (invariantly) assume that nlinks is accurate until readdir() :) Sure. The nlinks would only be used as a hint as to whether to cache or not. 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
Re: [Nfs-ganesha-devel] Work in Progress Readdir Chunking Posted
> On 02/23/2017 08:00 PM, Frank Filz wrote: > >> I have a first pass that works and passes pynfs! It isn't quite > >> correct in > > that a > >> rename into a directory or a create doesn't invalidate the dirent > >> cache > > and > >> thus a readdir might not show the new file. > >> > >> Unlink and rename out of a directory need not invalidate and should > >> work properly. > >> > >> Also left to do is memory management to constrain the total number of > >> dirents. > >> > >> The inode cache LRU reclaims the least recently used entry, however > >> that would cause problems for dirents since to reclaim one, we must > >> hold the content lock on the containing directory, but we also hold > >> the content > > lock on > >> the directory that needs another dirent. If the two directories > >> happen to > > be > >> involved in a rename from one directory to another, the order could > >> be reversed and create a deadlock. > >> > >> Another option is to have the LRU thread dispose of dirents from the > >> least recently used directories the same way it disposes of open > >> global file descriptors. That combined with logic that switched to > >> uncached mode if we couldn't get a free dirent would allow a reasonable > mechanism. > >> > >> Anyway, I encourage folks who are interested to take a look at the > >> WIP > > code > >> and play with it. > > > > And now directory invalidation is enabled for create, link, and rename. > > > > I think this is pretty close to complete. > > > > Please have at it, we will torture it at Connectathon next week. > > > > If we can gain a reasonable confidence, we can merge it this week, > > though that doesn't give people much time to review... > > > > It can be disabled by setting Dir_Chunk to 0 in the CacheInode config block. > > > > Still to be decided is how to interact with disabling dirent cache. > > Currently, with chunking enabled, we will never skip caching. Also, do > > we want to keep the legacy dirent cache? > > > > One proposal is to dump the legacy cache, and if Dir_Chunk is 0 then > > don't cache. > > I don't think we should ultimately keep both cache types. For now, while > we're testing, it's fine, but I think we should remove the old cache once we > have confidence in the chunked cache. Yea, that has been my thought. The only advantage to old cache would be for a filesystem that could not support seekdir and thus HAD to enumerate and cache an entire directory, especially if it could not provide a cookie Ganesha could use. Currently we don't have such a filesystem... 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
Re: [Nfs-ganesha-devel] Work in Progress Readdir Chunking Posted
Hi, - Original Message - > > Another thought is to look at the nlinks in the directory and decide to > cache or chunk. Please do not (invariantly) assume that nlinks is accurate until readdir() :) Matt > > 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 > -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 -- 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
[Nfs-ganesha-devel] Work in Progress Readdir Chunking Posted
I have a first pass that works and passes pynfs! It isn't quite correct in that a rename into a directory or a create doesn't invalidate the dirent cache and thus a readdir might not show the new file. Unlink and rename out of a directory need not invalidate and should work properly. Also left to do is memory management to constrain the total number of dirents. The inode cache LRU reclaims the least recently used entry, however that would cause problems for dirents since to reclaim one, we must hold the content lock on the containing directory, but we also hold the content lock on the directory that needs another dirent. If the two directories happen to be involved in a rename from one directory to another, the order could be reversed and create a deadlock. Another option is to have the LRU thread dispose of dirents from the least recently used directories the same way it disposes of open global file descriptors. That combined with logic that switched to uncached mode if we couldn't get a free dirent would allow a reasonable mechanism. Anyway, I encourage folks who are interested to take a look at the WIP code and play with it. 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
