With the count-per-lane fix, we can make lanes much bigger, like IBM does. On Mon, Aug 7, 2017 at 2:06 PM, Frank Filz <ffilz...@mindspring.com> wrote: > ject: Re: [Nfs-ganesha-devel] mdcache growing beyond limits. >> >> On 8/7/17 9:42 AM, Frank Filz wrote: >> >> It never has been. In cache_inode, a pin-ref kept it from being >> >> reaped, now any ref beyond 1 keeps it. >> > >> > Guess we need to do something about that... We need to put limits on >> state somewhere, that would take care of it mostly. We could still have some >> files in excess of high water mark due to active I/O threads, but that >> quantity >> is limited by the worker thread count. >> > >> That won't be true as the async I-O is added. Fewer threads will handle many >> more connections. > > Sure, but a given thread has at most 2 (or maybe 3) inode references. So N > workers means N*2 inodes possibly not available for reaping. Assuming high > water mark is much higher, we should be cool. > > Hmm, I wonder if we need more lanes than worker threads? > > 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
