[Nfs-ganesha-devel] drc refcnt
Hi, DRC refcnt is incremented on every get_drc. However, every nfs_dupreq_finish doesn't call a put_drc. How is it ensured that the drc refcnt drops to zero. On doing an umount, is drc eventually cleaned up. Thanks, Satya. -- 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] drc refcnt
Hi Satya, I don't -think- that's the case (that DRCs are leaked). If so, we would certainly wish to correct it. Malahal has most recently updated these code paths. Regards, Matt - Original Message - > From: "Satya Prakash GS" > To: nfs-ganesha-devel@lists.sourceforge.net > Sent: Monday, May 1, 2017 11:08:48 AM > Subject: [Nfs-ganesha-devel] drc refcnt > > Hi, > > DRC refcnt is incremented on every get_drc. However, every > nfs_dupreq_finish doesn't call a put_drc. How is it ensured that the > drc refcnt drops to zero. On doing an umount, is drc eventually > cleaned up. > > Thanks, > Satya. > > -- > 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
Re: [Nfs-ganesha-devel] drc refcnt
nfs_dupreq_finish() calls dupreq_entry_put() at about line 1238, and nfs_dupreq_put_drc() at about line 1222, so I think this is okay. Daniel On 05/01/2017 11:08 AM, Satya Prakash GS wrote: > Hi, > > DRC refcnt is incremented on every get_drc. However, every > nfs_dupreq_finish doesn't call a put_drc. How is it ensured that the > drc refcnt drops to zero. On doing an umount, is drc eventually > cleaned up. > > Thanks, > Satya. > > -- > 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 > -- 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] drc refcnt
Daniel, I meant to say - nfs_dupreq_finish doesn't call put_drc always. It does only if it meets certain criteria (drc_should_retire). Say the maxsize is 1000, hiwat is 800 and retire window size = 0. At the time of unmount if the drc size is just 100 wouldn't the refcount stay > 0. Thanks, Satya. >nfs_dupreq_finish() calls dupreq_entry_put() at about line 1238, and >nfs_dupreq_put_drc() at about line 1222, so I think this is okay. >Daniel >On 05/01/2017 11:08 AM, Satya Prakash GS wrote: >> Hi, >> >> DRC refcnt is incremented on every get_drc. However, every >> nfs_dupreq_finish doesn't call a put_drc. How is it ensured that the >> drc refcnt drops to zero. On doing an umount, is drc eventually >> cleaned up. >> >> Thanks, >> Satya. >> >> -- >> 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@... >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel >> On Mon, May 1, 2017 at 9:09 PM, Matt Benjamin wrote: > Hi Satya, > > I don't -think- that's the case (that DRCs are leaked). If so, we would > certainly wish to correct it. Malahal has most recently updated these code > paths. > > Regards, > > Matt > > ----- Original Message - >> From: "Satya Prakash GS" >> To: nfs-ganesha-devel@lists.sourceforge.net >> Sent: Monday, May 1, 2017 11:08:48 AM >> Subject: [Nfs-ganesha-devel] drc refcnt >> >> Hi, >> >> DRC refcnt is incremented on every get_drc. However, every >> nfs_dupreq_finish doesn't call a put_drc. How is it ensured that the >> drc refcnt drops to zero. On doing an umount, is drc eventually >> cleaned up. >> >> Thanks, >> Satya. >> >> -- >> 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
Re: [Nfs-ganesha-devel] drc refcnt
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. 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, 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. On Mon, May 1, 2017 at 10:42 PM, Satya Prakash GS wrote: > Daniel, > > I meant to say - nfs_dupreq_finish doesn't call put_drc always. It > does only if it meets certain criteria (drc_should_retire). > Say the maxsize is 1000, hiwat is 800 and retire window size = 0. > At the time of unmount if the drc size is just 100 wouldn't the > refcount stay > 0. > > Thanks, > Satya. > > >nfs_dupreq_finish() calls dupreq_entry_put() at about line 1238, and > >nfs_dupreq_put_drc() at about line 1222, so I think this is okay. > > >Daniel > > >On 05/01/2017 11:08 AM, Satya Prakash GS wrote: > >> Hi, > >> > >> DRC refcnt is incremented on every get_drc. However, every > >> nfs_dupreq_finish doesn't call a put_drc. How is it ensured that the > >> drc refcnt drops to zero. On doing an umount, is drc eventually > >> cleaned up. > >> > >> Thanks, > >> Satya. > >> > >> > -- > >> 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@... > >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > >> > > > On Mon, May 1, 2017 at 9:09 PM, Matt Benjamin > wrote: > > Hi Satya, > > > > I don't -think- that's the case (that DRCs are leaked). If so, we would > certainly wish to correct it. Malahal has most recently updated these code > paths. > > > > Regards, > > > > Matt > > > > - Original Message - > >> From: "Satya Prakash GS" > >> To: nfs-ganesha-devel@lists.sourceforge.net > >> Sent: Monday, May 1, 2017 11:08:48 AM > >> Subject: [Nfs-ganesha-devel] drc refcnt > >> > >> Hi, > >> > >> DRC refcnt is incremented on every get_drc. However, every > >> nfs_dupreq_finish doesn't call a put_drc. How is it ensured that the > >> drc refcnt drops to zero. On doing an umount, is drc eventually > >> cleaned up. > >> > >> Thanks, > >> Satya. > >> > >> > -- > >> 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 > -- 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] drc refcnt
> On Tue, May 2, 2017 at 7:58 AM, Malahal Naineni 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. -- 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] 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 wrote: > > On Tue, May 2, 2017 at 7:58 AM, Malahal Naineni > 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. > -- 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] drc refcnt
>On Tue, May 2, 2017 at 11:51 AM, Malahal Naineni wrote: > 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. Ok. > I think we should be freeing dupreq periodically using a timed function, > something like that drc_free_expired. Refcnt of the dupreq entries within the stale drc (of the disconnect client) is +ve since it starts at 2 (it is decremented once in nfs_dupreq_rele). First the refcnt of the dupreq_entries should be decremented and freed when it reaches 0. On freeing a dupreq entry, refcnt of drc should be decremented. All of the above should happen in free_expired or a similar function. > Regards, Malahal. Thanks, Satya. -- 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] drc refcnt
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" > To: "Satya Prakash GS" > Cc: "Matt Benjamin" , > 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 > wrote: > > > > On Tue, May 2, 2017 at 7:58 AM, Malahal Naineni > > 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
Re: [Nfs-ganesha-devel] drc refcnt
Matt, you are correct. We lose some memory (drc and dupreqs) for a client that never reconnects. Doing solely time based strategy is not scalable as well unless we fork multiple threads for doing this. My understanding is that there will be one time based strategy (hopefully, the time is long enough that it does not interfere with current strategy) in __addition__ to the current retiring strategy. Regards, Malahal. On Thu, May 4, 2017 at 3:56 AM, Matt Benjamin wrote: > 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" > > To: "Satya Prakash GS" > > Cc: "Matt Benjamin" , 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 > > > 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
Re: [Nfs-ganesha-devel] drc refcnt
Agree, existing retire logic in dupreq_finish will not be changed. In addition to this, stale drc objects will be handled in the timeout function. Stale drc objects are drcs which aren't referenced in a while (maintain last_used timestamp in drc and update it on every ref). This stale drc can have upto 1000 dupreq objects. static void handle_stale_drcs(drc_t *drc) { lock_drc; while (entry_exists_in_list(dupreq_q)) { dv = TAILQ_REMOVE(dupreq_q); dv->next = prev; prev = dv; } unlock_drc; Now the dupreq entries are in the list pointed to by dv; /* At this point only other references to dv are threads which are actively using the dv. * These threads will just do entry_put and not add the dv back to dupreq_q list. * So, we arrested all the double frees. */ while (entry_exists_in_list(dv)) { hk = dv->hk; lock_partition(hk); remove_from_rb_tree(dv); entry_put(dv); unlock_partition(hk); } put_drc(drc); } This is what I had in mind. I could possibly have missed some race. Thanks, Satya. On Thu, May 4, 2017 at 8:07 AM, Malahal Naineni wrote: > Matt, you are correct. We lose some memory (drc and dupreqs) for a client > that never reconnects. Doing solely time based strategy is not scalable as > well unless we fork multiple threads for doing this. My understanding is > that there will be one time based strategy (hopefully, the time is long > enough that it does not interfere with current strategy) in __addition__ to > the current retiring strategy. > > Regards, Malahal. > > On Thu, May 4, 2017 at 3:56 AM, Matt Benjamin wrote: >> >> 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" >> > To: "Satya Prakash GS" >> > Cc: "Matt Benjamin" , >> > 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 >> > >> > wrote: >> > >> > > > On Tue, May 2, 2017 at 7:58 AM, Malahal Naineni >> > > 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. >> > > >> > > >