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 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
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
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix race between mdcache_unexport and mdc_check_mapping
>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/359197 Change subject: Fix race between mdcache_unexport and mdc_check_mapping .. Fix race between mdcache_unexport and mdc_check_mapping Once we start an unexport, we must reject any new mappings between the export and cache entries. In fact, we can utilize mdc_check_mapping to shortcut and return ERR_FSAL_STALE for lookups and other operations that access an mdcache entry (they come through mdc_check_mapping to assure that the entry is mapped for an export it is accessed via). Because of the way the locking works, we check for unexport again before actually creating a new mapping just in case we had an unusual race between mdcache_unexport and mdc_check_mapping. Change-Id: I68b600c1996c7f41c7cd0b3124ce8cf1ac5c772a Signed-off-by: Frank S. Filz --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_export.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h 3 files changed, 68 insertions(+), 9 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/97/359197/1 -- To view, visit https://review.gerrithub.io/359197 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I68b600c1996c7f41c7cd0b3124ce8cf1ac5c772a Gerrit-Change-Number: 359197 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz -- 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
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
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 and non-cacheable ops
Hi Satya, That is expected, yes. I'm not aware of all possible implications. The issue of compound ops, specifically, is evidently only present in NFSv4.0 (or 4.1, the DRC is not used). Matt - Original Message - > From: "Satya Prakash GS" > To: nfs-ganesha-devel@lists.sourceforge.net > Sent: Monday, May 1, 2017 10:58:11 AM > Subject: Re: [Nfs-ganesha-devel] drc and non-cacheable ops > > Can somebody please reply to this. > > Thanks, > Satya. > > On Wed, Apr 26, 2017 at 3:02 PM, Satya Prakash GS > wrote: > > Hi, > > > > I have been looking at the drc code, I see operations like READ, > > READDIR, etc are not cached in drc. Can a compound operations have mix > > of both cacheable and non-cacheable operations. For example, can > > client send both SETATTR and READ as part of one compound operation > > (if concurrent operations are going on). If there is a mix of > > operations looks like DRC doesn't cache the operation. Is this ok ? > > > > 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
[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 and non-cacheable ops
Can somebody please reply to this. Thanks, Satya. On Wed, Apr 26, 2017 at 3:02 PM, Satya Prakash GS wrote: > Hi, > > I have been looking at the drc code, I see operations like READ, > READDIR, etc are not cached in drc. Can a compound operations have mix > of both cacheable and non-cacheable operations. For example, can > client send both SETATTR and READ as part of one compound operation > (if concurrent operations are going on). If there is a mix of > operations looks like DRC doesn't cache the operation. Is this ok ? > > 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
