Hi Guys, To get on the record here, the current retire strategy using new requests to retire old ones is an intrinsic good, particularly with TCP and related cots-ord transports where requests are totally ordered. I don't think moving to a strictly time-based strategy is preferable. Apparently the actually observed or theorized issue has to do with not disposing of requests in invalidated DRCs? That seems to be a special case, no?
Matt ----- Original Message ----- > From: "Malahal Naineni" <mala...@gmail.com> > To: "Satya Prakash GS" <g.satyaprak...@gmail.com> > Cc: "Matt Benjamin" <mbenja...@redhat.com>, > nfs-ganesha-devel@lists.sourceforge.net > Sent: Tuesday, May 2, 2017 2:21:48 AM > Subject: Re: [Nfs-ganesha-devel] drc refcnt > > Sorry, every cacheable request holds a ref on its DRC as well as its > DUPREQ. The ref on DUPREQ should be released when the request goes away > (via nfs_dupreq_rele). The ref on DRC will be released when the > corresponding DUPREQ request gets released. Since we release DUPREQs while > processing other requests, you are right that the DRC won't be freed if > there are no more requests that would use the same DRC. > > I think we should be freeing dupreq periodically using a timed function, > something like that drc_free_expired. > > Regards, Malahal. > > > > On Tue, May 2, 2017 at 10:38 AM, Satya Prakash GS <g.satyaprak...@gmail.com> > wrote: > > > > On Tue, May 2, 2017 at 7:58 AM, Malahal Naineni <mala...@gmail.com> > > wrote: > > > A dupreq will place a refcount on its DRC when it calls xxx_get_drc, so > > we > > > will release that DRC refcount when we free the dupreq. > > > > Ok, so every dupreq holds a ref on the drc. In case of drc cache hit, > > a dupreq entry can ref the > > drc more than once. This is still fine because unless the dupreq entry > > ref goes to zero the drc isn't freed. > > > > > nfs_dupreq_finish() shouldn't free its own dupreq. When it does free some > > > other dupreq, we will release DRC refcount corresponding to that dupreq. > > > > > When we free all dupreqs that belong to a DRC > > > > In the case of a disconnected client when are all the dupreqs freed ? > > > > When all the filesystem operations subside from a client (mount point > > is no longer in use), > > nfs_dupreq_finish doesn't get called anymore. This is the only place > > where dupreq entries are removed from > > the drc. If the entries aren't removed from drc, drc refcnt doesn't go to > > 0. > > > > >, its refcount should go to > > > zero (maybe another ref is held by the socket itself, so the socket has > > to > > > be closed as well). > > > > > > > > > In fact, if we release DRC refcount without freeing the dupreq, that > > would > > > be a bug! > > > > > > Regards, Malahal. > > > > > Thanks, > > Satya. > > > -- 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
