Re: [Nfs-ganesha-devel] drc and non-cacheable ops
Ok. DRC doesn't work on requests with cacheable and non-cacheable ops in it. Thank you Matt. Regards, Satya. On Mon, May 1, 2017 at 9:07 PM, Matt Benjamin wrote: > 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
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
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: gpfs: Remove unused REOPEN_BY_FD
>From Malahal : Malahal has uploaded this change for review. ( https://review.gerrithub.io/359265 Change subject: gpfs: Remove unused REOPEN_BY_FD .. gpfs: Remove unused REOPEN_BY_FD With support_ex, we don't need gpfs fsal's reopen method. Change-Id: Ie65b61340ed5c4e26b2c723f99b18be6a2b95804 Signed-off-by: Malahal Naineni --- M src/FSAL/FSAL_GPFS/file.c M src/FSAL/FSAL_GPFS/fsal_fileop.c M src/FSAL/FSAL_GPFS/fsal_internal.c M src/FSAL/FSAL_GPFS/fsal_internal.h M src/FSAL/FSAL_GPFS/fsal_lookup.c M src/FSAL/FSAL_GPFS/fsal_symlinks.c M src/FSAL/FSAL_GPFS/handle.c M src/FSAL/FSAL_GPFS/main.c 8 files changed, 24 insertions(+), 51 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/65/359265/1 -- To view, visit https://review.gerrithub.io/359265 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Ie65b61340ed5c4e26b2c723f99b18be6a2b95804 Gerrit-Change-Number: 359265 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal -- 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] user cred in FSAL when krb5 is used
Hi All,
What will an FSAL see when an AD user mounts a share using krb5 security?
is SYS security is used, FSAL gets uid/gid.
struct user_cred {
uid_t caller_uid;
gid_t caller_gid;
unsigned int caller_glen;
gid_t *caller_garray;
};
Looks like that structure supports only SYS security.
FSAL needs to see some identifier that uniquely identifies the AD user
accessing the share. Where can this info be found?
--Satish
Please Donate to www.wikipedia.org
--
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] user cred in FSAL when krb5 is used
fsal should get uid/gid stuff in krb5 authentication. The krb5
authentication and retrieval of uid/gid is part of core ganesha.
regards, malahal.
On Tue, May 2, 2017 at 7:27 PM, Satish Chandra Kilaru
wrote:
> Hi All,
>
> What will an FSAL see when an AD user mounts a share using krb5 security?
> is SYS security is used, FSAL gets uid/gid.
>
> struct user_cred {
> uid_t caller_uid;
> gid_t caller_gid;
> unsigned int caller_glen;
> gid_t *caller_garray;
> };
>
> Looks like that structure supports only SYS security.
>
> FSAL needs to see some identifier that uniquely identifies the AD user
> accessing the share. Where can this info be found?
>
> --Satish
> Please Donate to www.wikipedia.org
>
>
> --
> 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] I've got a new version of patches to help with unexport races
While working on this, I discovered some things that need to be done... NFS v4 rename and link do not check for xdev... I'm not sure that when the NFS v4 SavedFH is cleaned up (either being replaced, or released at end of compound) that it is cleaned up with the correct op_ctx, will check that and fix if not. 9P doesn't check for xdev in rename or link. I need to check that 9P sets a proper op_ctx when releasing object references (aka LRU references when MDCACHE is involved...). Rename isn't prevented from overwriting a junction. This would require fsal_rename to do a lookup on the target name (at which point we might as well pass the target object if any down to the FSAL for mdcache consumption...). If that is protected from overwriting a junction, then there is no risk of having the wrong op_ctx for cleanup. Hmm, I also need to make sure that NFS v3 and 9P junction crossing is done in a way that is unexport safe... This stuff probably didn't cause problems before MDCACHE because cache inode entry cleanup wasn't actually dependent on the proper export in op_ctx... Either that or no one did enough testing... 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
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Don't double deconstruct new entry in mdcache_new_entry
>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/359354 Change subject: Don't double deconstruct new entry in mdcache_new_entry .. Don't double deconstruct new entry in mdcache_new_entry The combination of mdcache_put and mdcache_kill_entry will deconstruct the new entry, so we actually were double deconstructing and causing problems. Also clarify the goto labels, and since the old "out" now "out_release_new_entry" is only called after nentry has been allocated there is no need to check for nentry being NULL (that may have been a holdover from before we aborted if memory allocation failed). Change-Id: Idf1e829d8d5c7258e239824ca91df2e84810e2bb Signed-off-by: Frank S. Filz --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c 3 files changed, 20 insertions(+), 31 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/54/359354/1 -- To view, visit https://review.gerrithub.io/359354 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Idf1e829d8d5c7258e239824ca91df2e84810e2bb Gerrit-Change-Number: 359354 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] I've got a new version of patches to help with unexport races
If anyone was looking for this, I finally got it pushed... Along the way I discovered that mdcache_new_entry is double deconstructing the entry on failure... > -Original Message- > From: Frank Filz [mailto:ffilz...@mindspring.com] > Sent: Tuesday, May 2, 2017 5:07 PM > To: nfs-ganesha-devel@lists.sourceforge.net > Subject: [Nfs-ganesha-devel] I've got a new version of patches to help with > unexport races > > While working on this, I discovered some things that need to be done... > > NFS v4 rename and link do not check for xdev... > > I'm not sure that when the NFS v4 SavedFH is cleaned up (either being > replaced, or released at end of compound) that it is cleaned up with the > correct op_ctx, will check that and fix if not. > > 9P doesn't check for xdev in rename or link. > > I need to check that 9P sets a proper op_ctx when releasing object > references (aka LRU references when MDCACHE is involved...). > > Rename isn't prevented from overwriting a junction. This would require > fsal_rename to do a lookup on the target name (at which point we might as > well pass the target object if any down to the FSAL for mdcache > consumption...). If that is protected from overwriting a junction, then there > is no risk of having the wrong op_ctx for cleanup. > > Hmm, I also need to make sure that NFS v3 and 9P junction crossing is done > in a way that is unexport safe... > > This stuff probably didn't cause problems before MDCACHE because cache > inode entry cleanup wasn't actually dependent on the proper export in > op_ctx... > Either that or no one did enough testing... > > 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 -- 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
