Re: [Nfs-ganesha-devel] DSESS9002 and DSESS9003 test cases result in NFS4ERR_GRACE

[Sriram Patil via Nfs-ganesha-devel]

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.Thanks Dan.

I will look into this one and try to figure out the right fix.

Thanks,
Sriram

From: Daniel Gryniewicz 
Sent: Monday, August 12, 2019 6:21 PM
To: nfs-ganesha-devel@lists.sourceforge.net 

Subject: Re: [Nfs-ganesha-devel] DSESS9002 and DSESS9003 test cases result in 
NFS4ERR_GRACE

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.
Jeff revamped Grace about a year ago as part of his work on clustered
FSAL_CEPH.  This may have fixed the issue.

Looking through, the only code that doesn't directly check the grace
state is the NFS4_OP_OPEN code.  If the client sends a CLAIM_NULL but
has not finished it's reclaim, then we'll return NFS4ERR_GRACE.  My
quick scan doesn't show us doing anything with that field when Grace
expires, so it's possible it hangs around...

Daniel

On 8/10/19 12:32 PM, Sriram Patil via Nfs-ganesha-devel wrote:
> This list has been deprecated. Please subscribe to the new devel list at 
> lists.nfs-ganesha.org.
>
>
> Hi,
>
> Was this fixed in some changes later? I have seen this a couple of times
> in some of our test runs.
>
> I have seen NFS4ERR_GRACE on open even when there are no NFS server
> restarts.
>
> Thanks,
> Sriram
> 
> *From:* Frank Filz 
> *Sent:* Friday, March 16, 2018 5:30 AM
> *To:* 'NFS Ganesha Developers' 
> *Subject:* [Nfs-ganesha-devel] DSESS9002 and DSESS9003 test cases result
> in NFS4ERR_GRACE
>
> Does anyone know why an open well after Ganesha comes up is returning
> NFS4ERR_GRACE?
>
> I think it has something to do with the cid_reclaim_complete in the NFS
> v4.1 clientid.
>
> Thanks
>
> Frank
>
>
>
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fnfs-ganesha-develdata=02%7C01%7Csriramp%40vmware.com%7C49446f6bf2a54a4c230908d71f27b61e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637012127733997819sdata=mfdQ49lBOLMn81gN4tkIm5LUUn891bafQUB%2BSSrr084%3Dreserved=0
>



___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fnfs-ganesha-develdata=02%7C01%7Csriramp%40vmware.com%7C49446f6bf2a54a4c230908d71f27b61e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637012127733997819sdata=mfdQ49lBOLMn81gN4tkIm5LUUn891bafQUB%2BSSrr084%3Dreserved=0
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] libntirpc not available anymore?

[Sriram Patil via Nfs-ganesha-devel]

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.
Thanks! I will check again.

- Sriram

On 3/4/19, 7:17 AM, "Daniel Gryniewicz"  wrote:

Over the weekend, the ntirpc repo was deleted.  I've restored it, and 
adjusted permissions so it shouldn't happen again.

Daniel

On 3/4/19 4:41 AM, Malahal Naineni wrote:
> This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.
> 
> 
> Very strange, you can add my remote 
> 
(https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmalahal%2Fntirpc.gitdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=BojyWaoCSXu84ZHSA9kiOqY%2FGATJDt0wvVlphE0hleU%3Dreserved=0)
 and fetch it in src/libntirpc. 
> It should have the latest commit needed, so "git submodule update –init 
> –recursive” should pass as long as you fetch the remote.
> 
> Regards, Malahal.
    > 
> On Mon, Mar 4, 2019 at 1:07 AM Sriram Patil via Nfs-ganesha-devel 
>  <mailto:nfs-ganesha-devel@lists.sourceforge.net>> wrote:
> 
> This list has been deprecated. Please subscribe to the new devel
> list at lists.nfs-ganesha.org 
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.nfs-ganesha.orgdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=5Wj6Vj4e1QhZkSoIkN%2B0XXBw6VtvWVt4LkmAFe%2BLgnA%3Dreserved=0>.
> 
> Hi,
> 
> __ __
> 
> I pulled in the latest ganesha code and tried to pull ntirpc with
> “git submodule update –init –recursive”. It is throwing following
> error,
> 
> __ __
> 
> Cloning into 'src/libntirpc'...
> 
> Username for 
'https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.comdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=Q74zeKIY%2FaW3mO4lEK0OhInrl1VKfSr%2FsJRApo%2BKoHA%3Dreserved=0':
 srirampatil
> 
> Password for 
'https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsrirampatil%40github.comdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=RQfcXKteEGXrwdaGF5gGYde9XNokpcylrP6s0yzj0R8%3Dreserved=0':
 
> 
> remote: Repository not found.
> 
> fatal: repository 
'https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfs-ganesha%2Fntirpc.git%2Fdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=JDEwSIzRYihAjZ2TnHk7Rg%2Frlbi0VTpWP1UBAt%2FoFCE%3Dreserved=0'
 not
> found
> 
> fatal: clone of 
'https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfs-ganesha%2Fntirpc.gitdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=vpWMyHfNQYVw1Ey8S8twUfnjQOIlXbFQ%2FHaHDnBmNbM%3Dreserved=0'
 into
> submodule path 'src/libntirpc' failed
> 
> __ __
> 
> __ __
> 
> The libntirpc repo does not exist anymore in nfs-ganesha account on
> github.
> 
> __ __
> 
> Thanks,
> 
> Sriram
> 
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fnfs-ganesha-develdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=YifXWSCvTUuEnW8%2Feqn04WOUvxttW0kDzAMETxwnAKk%3Dreserved=0
> 
> 
> 
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fnfs-ganesha-develdata=02%7C01%7Csriramp%40vmware.com%7Caf0cbd99d70540f2eab808d6a0b489da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636873094597157578sdata=YifXWSCvTUuEnW8%2Feqn04WOUvxttW0kDzAMETxwnAKk%3Dreserved=0
> 




___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] libntirpc not available anymore?

[Sriram Patil via Nfs-ganesha-devel]

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.Hi,

I pulled in the latest ganesha code and tried to pull ntirpc with “git 
submodule update –init –recursive”. It is throwing following error,

Cloning into 'src/libntirpc'...
Username for 'https://github.com': srirampatil
Password for 'https://srirampa...@github.com':
remote: Repository not found.
fatal: repository 'https://github.com/nfs-ganesha/ntirpc.git/' not found
fatal: clone of 'https://github.com/nfs-ganesha/ntirpc.git' into submodule path 
'src/libntirpc' failed


The libntirpc repo does not exist anymore in nfs-ganesha account on github.

Thanks,
Sriram
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] is_superuser fsal export API

[Sriram Patil]

Thanks for the clarification, Frank.

From: Frank Filz <ffilz...@mindspring.com>
Date: Tuesday, April 10, 2018 at 10:32 PM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] is_superuser fsal export API

The create calls and unlink all rely on the underlying filesystem to do 
permission checks. This is because there is no way for Ganesha to atomically 
check permissions in a directory and do an operation that adds or removes a 
directory entry.

Also, some FSAL_VFS operations set the thread credentials so that quota 
accounting and enforcement works properly.

So is_superuser can’t override the underlying filesystem’s notion of who is a 
superuser, it can only provide a mechanism for Ganesha to determine if a 
particular user is a superuser so that it can do the permission checks it does 
correctly.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Tuesday, April 10, 2018 8:13 AM
To: nfs-ganesha-devel@lists.sourceforge.net
Subject: [Nfs-ganesha-devel] is_superuser fsal export API

Hi,

This is in reference to the discussion we had on the concall.

We were experimenting with the is_superuser API call to allow a user other than 
the root to act as super user. This API call is not used by any of the FSALs 
currently. When using FSAL VFS, we found out that this mechanism works well in 
case of setattr (chown, chgrp, etc). But, all the create calls fail with 
permission denied. This is happening because in function vfs_open2, we set the 
uid/gid to the creds in op_ctx before calling openat. This brings in the linux 
access check into picture and if the superuser is not owner of the parent 
directory, this call fails with EACCESS.

Is this expected?

Thanks,
Sriram
--
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] is_superuser fsal export API

[Sriram Patil]

Hi,

This is in reference to the discussion we had on the concall.

We were experimenting with the is_superuser API call to allow a user other than 
the root to act as super user. This API call is not used by any of the FSALs 
currently. When using FSAL VFS, we found out that this mechanism works well in 
case of setattr (chown, chgrp, etc). But, all the create calls fail with 
permission denied. This is happening because in function vfs_open2, we set the 
uid/gid to the creds in op_ctx before calling openat. This brings in the linux 
access check into picture and if the superuser is not owner of the parent 
directory, this call fails with EACCESS.

Is this expected?

Thanks,
Sriram
--
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] NFSv4 recovery directory path

[Sriram Patil]

Hi,

Currently the NFSv4 recovery directory root path is as good as hard coded 
because it depends on the CMAKE_INSTALL_PREFIX. It is can be found in config.h 
after running cmake.  I tried specifying a –DNFS_V4_RECOV_ROOT= when 
compiling, but it does not work because config.h overwrites the variable. 
Writing a new recovery backend seems like too much of a hassle for changing 
just the path.

Is there any way (may be a conf param I am missing) to change the recovery root 
directory?

Thanks,
Sriram
--
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] About referrals in FSAL_VFS

[sriram patil]

The other way is instead of removing the fs_locations callback from object
ops we can add attrlist as one more parameter to the function and pull the
attrs from mdcache and pass it down to fsal. Fsal can then parse the
strings and fill the fsroot and servers.

On Mon 12 Mar, 2018, 8:02 PM Sriram Patil, <srir...@vmware.com> wrote:

> Some questions about this implementation.
>
>
>
> We should be filling the fs_locations in attrs as part of getattrs now,
> this can be done by subfsal getattrs callback so that subfsals have control
> over the fs_locations. But, with this, we may not require the fs_locations
> callback in the obj_ops. Is ti okay to get rid of the fs_locations callback
> or should I just add a comment mentioning this will be deprecated? It will
> also require changes in the existing FSALs which use the fs_locations
> callback currently. What do you think?
>
>
>
> Thanks,
>
> Sriram
>
>
>
> *From: *Sriram Patil <srir...@vmware.com>
> *Date: *Saturday, March 10, 2018 at 8:30 PM
> *To: *Frank Filz <ffilz...@mindspring.com>, "
> nfs-ganesha-devel@lists.sourceforge.net" <
> nfs-ganesha-devel@lists.sourceforge.net>
> *Subject: *Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
>
>
>
> Okay, sounds good. Will work towards getting this right.
>
>
>
> Thanks,
>
> Sriram
>
>
>
> *From: *Frank Filz <ffilz...@mindspring.com>
> *Date: *Friday, March 9, 2018 at 11:20 PM
> *To: *Sriram Patil <srir...@vmware.com>, "
> nfs-ganesha-devel@lists.sourceforge.net" <
> nfs-ganesha-devel@lists.sourceforge.net>
> *Subject: *RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS
>
>
>
> Hmm, did I sow confusion about fs_locations in attrlist? I think that
> would be the best solution. We do need to work to be careful about tracking
> the validity of different parts of the attrlist, since we don’t necessarily
> want to fetch the fs_locations from the filesystem every time we refresh
> attributes.
>
>
>
> I think with fs_locations being in the attrlist, it becomes much easier to
> have a sub-fsal with different handling.
>
>
> Frank
>
>
>
> *From:* Sriram Patil [mailto:srir...@vmware.com]
> *Sent:* Friday, March 9, 2018 9:09 AM
> *To:* Frank Filz <ffilz...@mindspring.com>;
> nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
>
>
>
> Hi Frank,
>
>
>
> Now that the referral fixes for pynfs are approved (not merged yet), I
> wanted to work on the subfsal layer to extend this to subfsal and allow
> having referral points as desired. As we had discussed before, it would be
> a good idea to store fs locations in the attrlist, but a few days back on
> IRC you mentioned that we do not want to jump onto that as yet. So, I was
> thinking of supporting referrals and fs_locations at subfsal layer a little
> differently which will not involve a lot of changes.
>
>
>
> Currently, the vfs_fsal_obj_handle stores fsroot and fslocations as part
> of directory (hdl->u.directory). I was thinking of moving these out of the
> union and make them first class variable in the structure or the union
> inside it. This way the fsroot and fslocations can be stored for any file
> type, for example a symlink. I will be adding some subfsal callbacks for
> populating and retrieving the fslocation details as discussed before.
>
>
>
> Let me know if this looks like a good thing to do or should we think about
> fslocations in attrlist?
>
>
>
> Thanks,
>
> Sriram
>
>
>
> *From: *Sriram Patil <srir...@vmware.com>
> *Date: *Friday, February 9, 2018 at 10:30 AM
> *To: *Frank Filz <ffilz...@mindspring.com>, "
> nfs-ganesha-devel@lists.sourceforge.net" <
> nfs-ganesha-devel@lists.sourceforge.net>
> *Subject: *Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
>
>
>
> Okay, so there are a bunch of things that we need to do. I will just list
> them down here, let me know if I miss anything.
>
>1. Fs locations can be moved to attrlist and FSAL can fill it as part
>of getattr if required
>2. We need ref counting for fs locations for handling attr copy where
>multiple objects can hold reference to fs locations
>3. Have a validity bit for fs locations. Allow a dbus command to
>invalidate all fs_locations to be able to refresh the locations for dynamic
>updates
>4. Add methods/callbacks to subfsal mechanism to allow subfsals to
>choose how referrals work for them. This should also allow a way to follow
>the default VFS mechanism
>
>
>
> Thanks,
>
> Sriram
>
>
>
>

Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

[Sriram Patil]

Some questions about this implementation.

We should be filling the fs_locations in attrs as part of getattrs now, this 
can be done by subfsal getattrs callback so that subfsals have control over the 
fs_locations. But, with this, we may not require the fs_locations callback in 
the obj_ops. Is ti okay to get rid of the fs_locations callback or should I 
just add a comment mentioning this will be deprecated? It will also require 
changes in the existing FSALs which use the fs_locations callback currently. 
What do you think?

Thanks,
Sriram

From: Sriram Patil <srir...@vmware.com>
Date: Saturday, March 10, 2018 at 8:30 PM
To: Frank Filz <ffilz...@mindspring.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Okay, sounds good. Will work towards getting this right.

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Friday, March 9, 2018 at 11:20 PM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hmm, did I sow confusion about fs_locations in attrlist? I think that would be 
the best solution. We do need to work to be careful about tracking the validity 
of different parts of the attrlist, since we don’t necessarily want to fetch 
the fs_locations from the filesystem every time we refresh attributes.

I think with fs_locations being in the attrlist, it becomes much easier to have 
a sub-fsal with different handling.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Friday, March 9, 2018 9:09 AM
To: Frank Filz <ffilz...@mindspring.com>; 
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hi Frank,

Now that the referral fixes for pynfs are approved (not merged yet), I wanted 
to work on the subfsal layer to extend this to subfsal and allow having 
referral points as desired. As we had discussed before, it would be a good idea 
to store fs locations in the attrlist, but a few days back on IRC you mentioned 
that we do not want to jump onto that as yet. So, I was thinking of supporting 
referrals and fs_locations at subfsal layer a little differently which will not 
involve a lot of changes.

Currently, the vfs_fsal_obj_handle stores fsroot and fslocations as part of 
directory (hdl->u.directory). I was thinking of moving these out of the union 
and make them first class variable in the structure or the union inside it. 
This way the fsroot and fslocations can be stored for any file type, for 
example a symlink. I will be adding some subfsal callbacks for populating and 
retrieving the fslocation details as discussed before.

Let me know if this looks like a good thing to do or should we think about 
fslocations in attrlist?

Thanks,
Sriram

From: Sriram Patil <srir...@vmware.com<mailto:srir...@vmware.com>>
Date: Friday, February 9, 2018 at 10:30 AM
To: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>, 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Okay, so there are a bunch of things that we need to do. I will just list them 
down here, let me know if I miss anything.

  1.  Fs locations can be moved to attrlist and FSAL can fill it as part of 
getattr if required
  2.  We need ref counting for fs locations for handling attr copy where 
multiple objects can hold reference to fs locations
  3.  Have a validity bit for fs locations. Allow a dbus command to invalidate 
all fs_locations to be able to refresh the locations for dynamic updates
  4.  Add methods/callbacks to subfsal mechanism to allow subfsals to choose 
how referrals work for them. This should also allow a way to follow the default 
VFS mechanism

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>
Date: Friday, February 9, 2018 at 12:05 AM
To: Sriram Patil <srir...@vmware.com<mailto:srir...@vmware.com>>, 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

There are places the struct attrlist gets copied, if so, either the referral 
needs to be duplicated in that copy, or it needs to be a single entity with a 
refcount.

One advantage of adding the referral to the struct attrlist is that MDCACHE 
will manage cache life of it.

It may or may not be worth having a separate cache validity bit for it 
(advantage of doing that is the

Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

[Sriram Patil]

Okay, sounds good. Will work towards getting this right.

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Friday, March 9, 2018 at 11:20 PM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hmm, did I sow confusion about fs_locations in attrlist? I think that would be 
the best solution. We do need to work to be careful about tracking the validity 
of different parts of the attrlist, since we don’t necessarily want to fetch 
the fs_locations from the filesystem every time we refresh attributes.

I think with fs_locations being in the attrlist, it becomes much easier to have 
a sub-fsal with different handling.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Friday, March 9, 2018 9:09 AM
To: Frank Filz <ffilz...@mindspring.com>; 
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hi Frank,

Now that the referral fixes for pynfs are approved (not merged yet), I wanted 
to work on the subfsal layer to extend this to subfsal and allow having 
referral points as desired. As we had discussed before, it would be a good idea 
to store fs locations in the attrlist, but a few days back on IRC you mentioned 
that we do not want to jump onto that as yet. So, I was thinking of supporting 
referrals and fs_locations at subfsal layer a little differently which will not 
involve a lot of changes.

Currently, the vfs_fsal_obj_handle stores fsroot and fslocations as part of 
directory (hdl->u.directory). I was thinking of moving these out of the union 
and make them first class variable in the structure or the union inside it. 
This way the fsroot and fslocations can be stored for any file type, for 
example a symlink. I will be adding some subfsal callbacks for populating and 
retrieving the fslocation details as discussed before.

Let me know if this looks like a good thing to do or should we think about 
fslocations in attrlist?

Thanks,
Sriram

From: Sriram Patil <srir...@vmware.com<mailto:srir...@vmware.com>>
Date: Friday, February 9, 2018 at 10:30 AM
To: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>, 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Okay, so there are a bunch of things that we need to do. I will just list them 
down here, let me know if I miss anything.

  1.  Fs locations can be moved to attrlist and FSAL can fill it as part of 
getattr if required
  2.  We need ref counting for fs locations for handling attr copy where 
multiple objects can hold reference to fs locations
  3.  Have a validity bit for fs locations. Allow a dbus command to invalidate 
all fs_locations to be able to refresh the locations for dynamic updates
  4.  Add methods/callbacks to subfsal mechanism to allow subfsals to choose 
how referrals work for them. This should also allow a way to follow the default 
VFS mechanism

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>
Date: Friday, February 9, 2018 at 12:05 AM
To: Sriram Patil <srir...@vmware.com<mailto:srir...@vmware.com>>, 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

There are places the struct attrlist gets copied, if so, either the referral 
needs to be duplicated in that copy, or it needs to be a single entity with a 
refcount.

One advantage of adding the referral to the struct attrlist is that MDCACHE 
will manage cache life of it.

It may or may not be worth having a separate cache validity bit for it 
(advantage of doing that is then 9P and V3 GETATTR won’t need to fetch it. 
Also, conceivably we could have a dBUS trigger to invalidate all referral 
attributes (on the other hand, without a separate validity bit, that dBUS 
command could just invalidate the attributes of any object that had a non-empty 
referral, though that would delay when a fs_locations attribute becomes visible 
if added to an object that previously didn’t have one…) I think I just talked 
myself into a separate validity bit. We will want to be able to tell Ganesha to 
refresh fs_locations, it can march through all the cached inodes and invalidate 
the fs_locations attribute (whether it was empty or not) thus allowing 
dynamically moving a sub-tree.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Thursday, February 8, 2018 9:33 AM
To: Frank Filz <ffilz...@mindspring.com<m

Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

[Sriram Patil]

Hi Frank,

Now that the referral fixes for pynfs are approved (not merged yet), I wanted 
to work on the subfsal layer to extend this to subfsal and allow having 
referral points as desired. As we had discussed before, it would be a good idea 
to store fs locations in the attrlist, but a few days back on IRC you mentioned 
that we do not want to jump onto that as yet. So, I was thinking of supporting 
referrals and fs_locations at subfsal layer a little differently which will not 
involve a lot of changes.

Currently, the vfs_fsal_obj_handle stores fsroot and fslocations as part of 
directory (hdl->u.directory). I was thinking of moving these out of the union 
and make them first class variable in the structure or the union inside it. 
This way the fsroot and fslocations can be stored for any file type, for 
example a symlink. I will be adding some subfsal callbacks for populating and 
retrieving the fslocation details as discussed before.

Let me know if this looks like a good thing to do or should we think about 
fslocations in attrlist?

Thanks,
Sriram

From: Sriram Patil <srir...@vmware.com>
Date: Friday, February 9, 2018 at 10:30 AM
To: Frank Filz <ffilz...@mindspring.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Okay, so there are a bunch of things that we need to do. I will just list them 
down here, let me know if I miss anything.

  1.  Fs locations can be moved to attrlist and FSAL can fill it as part of 
getattr if required
  2.  We need ref counting for fs locations for handling attr copy where 
multiple objects can hold reference to fs locations
  3.  Have a validity bit for fs locations. Allow a dbus command to invalidate 
all fs_locations to be able to refresh the locations for dynamic updates
  4.  Add methods/callbacks to subfsal mechanism to allow subfsals to choose 
how referrals work for them. This should also allow a way to follow the default 
VFS mechanism

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Friday, February 9, 2018 at 12:05 AM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

There are places the struct attrlist gets copied, if so, either the referral 
needs to be duplicated in that copy, or it needs to be a single entity with a 
refcount.

One advantage of adding the referral to the struct attrlist is that MDCACHE 
will manage cache life of it.

It may or may not be worth having a separate cache validity bit for it 
(advantage of doing that is then 9P and V3 GETATTR won’t need to fetch it. 
Also, conceivably we could have a dBUS trigger to invalidate all referral 
attributes (on the other hand, without a separate validity bit, that dBUS 
command could just invalidate the attributes of any object that had a non-empty 
referral, though that would delay when a fs_locations attribute becomes visible 
if added to an object that previously didn’t have one…) I think I just talked 
myself into a separate validity bit. We will want to be able to tell Ganesha to 
refresh fs_locations, it can march through all the cached inodes and invalidate 
the fs_locations attribute (whether it was empty or not) thus allowing 
dynamically moving a sub-tree.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Thursday, February 8, 2018 9:33 AM
To: Frank Filz <ffilz...@mindspring.com>; 
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

attrlist changes sound good. I am trying to figure out the necessity of a 
separate cache and ref counts. As far as I see, there will not be multiple 
references to fs_locations (which will be just a string in attrlist).

What do you mean by xattr utility is being added in nfs-utils? Is that 
nfs-utils package? Is it just a package dependency or something else?

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil <srir...@vmware.com<mailto:srir...@vmware.com>>, 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Ok, the additional sub_fsal ops look workable.

For the protocol layer stuff, we need a quick way to check if an object is a 
junction. One option is to resurrect the fsal_obj_handle JUNCTION type. Another 
option is to add fs_locations to struct attrlist and then an FSAL supporting 
referral objects would just set that attribute (reading the xattr for those 
implementations). That would mean the fs_locations attribute is a

Re: [Nfs-ganesha-devel] ACL support

[Sriram Patil]

Thank you for the correction, Frank.

Sagar, there are a couple of more things that you have not mentioned yet,


  1.  Have you set ATTR_ACL in supported_attrs field of your FSALs static 
fsinfo? (check usage of function nfs4_Fattr_Supported to know why this is 
required)
  2.  You may also want to take a look at ENABLE_RFC_ACL flag. This is not for 
enabling ACLs but it is used for access checks in fsal_check_access_acl.

- Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Friday, February 16, 2018 at 8:19 PM
To: Sriram Patil <srir...@vmware.com>, 'Sagar M D' <sagar...@gmail.com>, 
'Supriti Singh' <supriti.si...@suse.com>
Cc: "nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] ACL support

It isn’t quite true that NFS v4 ACLs are a superset of POSIX ACLs, but that’s 
another detail.

Sriram is right, Ganesha doesn’t support the NFS v3 sideband protocol for POSIX 
ACLs. At this point Ganesha has the following support for ACLs:

FSAL_GLUSTER has a translation from client side NFS v4 ACLs to server side 
POSIX ACLs. In V2.7 we plan to move this support to the FSAL common code so it 
is available to more FSALs (and we will hook it up for FSAL_VFS at that point). 
Note that the conversion is not perfect due to NFS v4 ACLs not actually being a 
superset of POSIX ACLs.

FSAL_GPFS has native support for NFS v4 ACLs.

At this time Ganesha is only set up to handle NFS v4 ACLs via the FSAL API. If 
your file system can support NFS v4 ACLs natively, then all you need to do is 
provide a mechanism to transfer between Ganesha’s in memory representation of 
an NFS v4 ACL and your on-disk representation. If your file system can only 
support POSIX ACLs, then you will need the translation code from FSAL_GLUSTER 
(or write your own).

I’d also like to add my usual plug, if you have an out of tree FSAL, we 
encourage you to submit your FSAL into the tree. That allows us a better 
understanding of how Ganesha is being used, and we are less likely to change 
APIs in a way that breaks your FSAL (or we will change your FSAL with the API 
change).

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Friday, February 16, 2018 2:51 AM
To: Sagar M D <sagar...@gmail.com>; Supriti Singh <supriti.si...@suse.com>
Cc: nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] ACL support

Hi Sagar,

I see in your conf file that you are using NFSv4. POSIX acls do not work on 
NFSv4. NFSv4 acls are a superset of POSIX acls. For using NFSv4 acls you need 
to use nfs4_getfacl and nfs4_setfacl commands from the client. You can find 
these commands in nfs4-acl-tools package.

- Sriram

From: Sagar M D <sagar...@gmail.com<mailto:sagar...@gmail.com>>
Date: Friday, February 16, 2018 at 3:20 PM
To: Supriti Singh <supriti.si...@suse.com<mailto:supriti.si...@suse.com>>
Cc: 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: Re: [Nfs-ganesha-devel] ACL support

I quickly checked on VFS FSAL using below EXPORT block. I see same issue on vfs 
fsal also. Any suggestion here please ?

Operation to request attribute not supported.
Failed to instantiate ACL.


EXPORT
{
Export_Id = 77;

# Exported path (mandatory)
Path = /home;

# Pseudo Path (required for NFS v4)
Pseudo = /home;

# Required for access (default is None)
# Could use CLIENT blocks instead
Access_Type = RW;
Disable_ACL = FALSE;
NFS_Protocols = 4;
Squash = no_root_squash;

# Exporting FSAL
FSAL {
Name = VFS;
}
}
Thanks,
Sagar.


On Fri, Feb 16, 2018 at 2:25 PM, Sagar M D 
<sagar...@gmail.com<mailto:sagar...@gmail.com>> wrote:
Supriti,

We are testing our own FSAL.
Thanks,
Sagar.


On Fri, Feb 16, 2018 at 2:15 PM, Supriti Singh 
<supriti.si...@suse.com<mailto:supriti.si...@suse.com>> wrote:
Hi Sagar,

Which FSAL are you using?


--
Supriti Singh
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

>>> Sagar M D <sagar...@gmail.com<mailto:sagar...@gmail.com>> 02/16/18 9:15 AM 
>>> >>>
Hi,

We are setting below value in our EXPORT block to enable ACL.
Disable_ACL = FALSE;
However when try to do any ACL operation it throws get below error:-
Operation to request attribute not supported.
Failed to instantiate ACL.
On further analysis, i found that getattr call on our fsal  export's root 
folder is returning 3 (ALLOW | DENY) in aclsupport field. But getattr call on 
pseudo export is returning "0" in aclsupport field.


Is there anything else in fsal to be taken care to enable acls ?

Thanks,
Sagar.

Re: [Nfs-ganesha-devel] ACL support

[Sriram Patil]

Hi Sagar,

I see in your conf file that you are using NFSv4. POSIX acls do not work on 
NFSv4. NFSv4 acls are a superset of POSIX acls. For using NFSv4 acls you need 
to use nfs4_getfacl and nfs4_setfacl commands from the client. You can find 
these commands in nfs4-acl-tools package.

- Sriram

From: Sagar M D 
Date: Friday, February 16, 2018 at 3:20 PM
To: Supriti Singh 
Cc: "nfs-ganesha-devel@lists.sourceforge.net" 

Subject: Re: [Nfs-ganesha-devel] ACL support

I quickly checked on VFS FSAL using below EXPORT block. I see same issue on vfs 
fsal also. Any suggestion here please ?

Operation to request attribute not supported.
Failed to instantiate ACL.


EXPORT
{
Export_Id = 77;

# Exported path (mandatory)
Path = /home;

# Pseudo Path (required for NFS v4)
Pseudo = /home;

# Required for access (default is None)
# Could use CLIENT blocks instead
Access_Type = RW;
Disable_ACL = FALSE;
NFS_Protocols = 4;
Squash = no_root_squash;

# Exporting FSAL
FSAL {
Name = VFS;
}
}
Thanks,
Sagar.



On Fri, Feb 16, 2018 at 2:25 PM, Sagar M D 
> wrote:
Supriti,

We are testing our own FSAL.
Thanks,
Sagar.


On Fri, Feb 16, 2018 at 2:15 PM, Supriti Singh 
> wrote:
Hi Sagar,

Which FSAL are you using?



--
Supriti Singh
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

>>> Sagar M D > 02/16/18 9:15 AM 
>>> >>>
Hi,

We are setting below value in our EXPORT block to enable ACL.
Disable_ACL = FALSE;
However when try to do any ACL operation it throws get below error:-
Operation to request attribute not supported.
Failed to instantiate ACL.
On further analysis, i found that getattr call on our fsal  export's root 
folder is returning 3 (ALLOW | DENY) in aclsupport field. But getattr call on 
pseudo export is returning "0" in aclsupport field.


Is there anything else in fsal to be taken care to enable acls ?

Thanks,
Sagar.




--
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] pynfs fslocations tests failure

[Sriram Patil]

Hi,

I was testing the pynfs fslocations tests on latest code base with VFS mounts 
on ext4 and have found that most of the tests fail. Are these known issues? 
Please find the command and the output below

> showmount –e
Export list for localhost.localdomain:
/exports/default (everyone)
/exports/sriram  (everyone)

Note: /exports/default/sriram_ref is the referral directory

> ./testserver.py localhost:/exports/default --maketree -v --usespecial 
> /exports/default/sriram_ref  --rundeps fslocations

FSLOC1   st_fslocations.testReference : FAILURE
   GETFH of path indicated by --usespecial should return
   NFS4ERR_MOVED, instead got NFS4_OK
FSLOC2   st_fslocations.testReference2: PASS
FSLOC3   st_fslocations.testReference3: PASS
FSLOC4a  st_fslocations.testAttr1a: PASS
FSLOC4b  st_fslocations.testAttr1b: PASS
FSLOC5a  st_fslocations.testAttr2a: PASS
FSLOC5b  st_fslocations.testAttr2b: FAILURE
   Expected 2 attrs returned for file sriram_ref, got 1
FSLOC6a  st_fslocations.testAttr3a: FAILURE
   GETATTR w/o FSLOC but only restricted attrs should
   return NFS4_OK, instead got NFS4ERR_MOVED
FSLOC6b  st_fslocations.testAttr3b: FAILURE
   Expected 3 attrs returned for file sriram_ref, got 1
FSLOC7a  st_fslocations.testAttr4a: FAILURE
   Expected 3 attrs returned, got 5
FSLOC7b  st_fslocations.testAttr4b: FAILURE
   Expected 3 attrs returned for file sriram_ref, got 1
FSLOC8a  st_fslocations.testAttr5a: FAILURE
   Expected 3 attrs returned, got 4
FSLOC8b  st_fslocations.testAttr5b: FAILURE
   BadCompoundRes: READDIR with cookie=0, maxcount=4096:
   operation OP_READDIR should return NFS4_OK, instead
   got NFS4ERR_MOVED
GATT8st_getattr.testFSLocations   : PASS
LOOKFILE st_lookup.testFile   : PASS

Thanks,
Sriram
--
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] About referrals in FSAL_VFS

[Sriram Patil]

Okay, so there are a bunch of things that we need to do. I will just list them 
down here, let me know if I miss anything.

  1.  Fs locations can be moved to attrlist and FSAL can fill it as part of 
getattr if required
  2.  We need ref counting for fs locations for handling attr copy where 
multiple objects can hold reference to fs locations
  3.  Have a validity bit for fs locations. Allow a dbus command to invalidate 
all fs_locations to be able to refresh the locations for dynamic updates
  4.  Add methods/callbacks to subfsal mechanism to allow subfsals to choose 
how referrals work for them. This should also allow a way to follow the default 
VFS mechanism

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Friday, February 9, 2018 at 12:05 AM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

There are places the struct attrlist gets copied, if so, either the referral 
needs to be duplicated in that copy, or it needs to be a single entity with a 
refcount.

One advantage of adding the referral to the struct attrlist is that MDCACHE 
will manage cache life of it.

It may or may not be worth having a separate cache validity bit for it 
(advantage of doing that is then 9P and V3 GETATTR won’t need to fetch it. 
Also, conceivably we could have a dBUS trigger to invalidate all referral 
attributes (on the other hand, without a separate validity bit, that dBUS 
command could just invalidate the attributes of any object that had a non-empty 
referral, though that would delay when a fs_locations attribute becomes visible 
if added to an object that previously didn’t have one…) I think I just talked 
myself into a separate validity bit. We will want to be able to tell Ganesha to 
refresh fs_locations, it can march through all the cached inodes and invalidate 
the fs_locations attribute (whether it was empty or not) thus allowing 
dynamically moving a sub-tree.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Thursday, February 8, 2018 9:33 AM
To: Frank Filz <ffilz...@mindspring.com>; 
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

attrlist changes sound good. I am trying to figure out the necessity of a 
separate cache and ref counts. As far as I see, there will not be multiple 
references to fs_locations (which will be just a string in attrlist).

What do you mean by xattr utility is being added in nfs-utils? Is that 
nfs-utils package? Is it just a package dependency or something else?

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil <srir...@vmware.com<mailto:srir...@vmware.com>>, 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Ok, the additional sub_fsal ops look workable.

For the protocol layer stuff, we need a quick way to check if an object is a 
junction. One option is to resurrect the fsal_obj_handle JUNCTION type. Another 
option is to add fs_locations to struct attrlist and then an FSAL supporting 
referral objects would just set that attribute (reading the xattr for those 
implementations). That would mean the fs_locations attribute is always fetched, 
perhaps slowing down getattrs for all referral objects even if the caller isn’t 
going to trigger use of the referral, but one hopes there aren’t too many 
referrals (and most access, at least via NFS v4, will trigger the fs_locations 
anyway).

I think I actually like adding fs_locations to struct attrlist (note that it 
will add a 2nd attribute like ACL that probably should be refcounted etc.). The 
consequences of forgetting to check for fs_locations attribute somewhere in 
code will be less than not handling the JUNCTION type.

Interesting, a utility to manage the xattr is being added to nfs-utils…

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, February 7, 2018 6:06 PM
To: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>; 
nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

So, any subfsal for a filesystem which does not support xattrs cannot work with 
the current FSAL_VFS referrals mechanism. Ideally, it would be good to have 
subfsal callbacks, the way we have it for other things in ganesha. It will look 
much better instead of overriding a set of functions declared in subfsal.h. 
But, let’s push this for some other day and keep it open for discussion. I was 
thinking of making this cha

Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

[Sriram Patil]

attrlist changes sound good. I am trying to figure out the necessity of a 
separate cache and ref counts. As far as I see, there will not be multiple 
references to fs_locations (which will be just a string in attrlist).

What do you mean by xattr utility is being added in nfs-utils? Is that 
nfs-utils package? Is it just a package dependency or something else?

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Ok, the additional sub_fsal ops look workable.

For the protocol layer stuff, we need a quick way to check if an object is a 
junction. One option is to resurrect the fsal_obj_handle JUNCTION type. Another 
option is to add fs_locations to struct attrlist and then an FSAL supporting 
referral objects would just set that attribute (reading the xattr for those 
implementations). That would mean the fs_locations attribute is always fetched, 
perhaps slowing down getattrs for all referral objects even if the caller isn’t 
going to trigger use of the referral, but one hopes there aren’t too many 
referrals (and most access, at least via NFS v4, will trigger the fs_locations 
anyway).

I think I actually like adding fs_locations to struct attrlist (note that it 
will add a 2nd attribute like ACL that probably should be refcounted etc.). The 
consequences of forgetting to check for fs_locations attribute somewhere in 
code will be less than not handling the JUNCTION type.

Interesting, a utility to manage the xattr is being added to nfs-utils…

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, February 7, 2018 6:06 PM
To: Frank Filz <ffilz...@mindspring.com>; 
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

So, any subfsal for a filesystem which does not support xattrs cannot work with 
the current FSAL_VFS referrals mechanism. Ideally, it would be good to have 
subfsal callbacks, the way we have it for other things in ganesha. It will look 
much better instead of overriding a set of functions declared in subfsal.h. 
But, let’s push this for some other day and keep it open for discussion. I was 
thinking of making this change without doing much changes in the current 
framework. This is what I would like to do,

Add a couple of functions in subfsal.h for allowing subfsals to decide how 
referrals work. For example,

bool vfs_is_referral_handle(struct vfs_fsal_obj_handle *hdl, struct attrlist 
*atrs); - we check for the attributes and file types here to decide whether it 
is a referral

fsal_status_t vfs_fetch_referral_locations(struct vfs_fsal_obj_handle *hdl) – 
read the fs_locations (currently through xattrs) and store them where ever 
desired (currently stored in hdl->u.directory.fs_location)

Add fs_locations callback in vfs_subfsal_obj_ops, to allow subfsals manage the 
fs_locations on their own.

Both these methods will have a default implementation in FSAL_VFS. So, a 
subfsal can keep using the current mechanism.

However, this is not sufficient. The directory and sticky bit referral is also 
checked in nfs4_op_getattr and nfs4_op_readdir. Need to figure out how to get 
rid of that.

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.com>>
Date: Thursday, February 8, 2018 at 12:24 AM
To: Sriram Patil <srir...@vmware.com<mailto:srir...@vmware.com>>, 
"nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>"
 
<nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

If you could share the details of what you want to do differently we can 
discuss the best way to accomplish that.

After the research on what it would take to eliminate sub-FSAL, it’s clear that 
is here to stay, and extending the sub-FSAL API could be the best solution.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, February 7, 2018 7:06 AM
To: 
nfs-ganesha-devel@lists.sourceforge.net<mailto:nfs-ganesha-devel@lists.sourceforge.net>
Subject: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hi,

I understand that we are not supposed to extend subfsals and should move to 
Stackable FSALs. But, since it is not possible in some cases (e.g. 
open_by_handle is not supported by the kernel), subfsal has to stay.

Currently, the referrals decision is made by FSAL_VFS depending on a specific 
set of attributes and user.fs_location xattr value. If a subfsal wants to 
achieve this with some other mechanism, there is no way to do that in the 
current code. So, I wanted to extend the referrals functionality in FSAL_VFS 
and make it more flexible by allowing subfsa

Re: [Nfs-ganesha-devel] New things in feature board

[Sriram Patil]

Hi Supriti,

The link you have provided is not working. And the 2.7 board seems to be 
closed. I checked things here - 
https://github.com/nfs-ganesha/nfs-ganesha/projects. Am I missing something?

Thanks,
Sriram

From: Supriti Singh 
Date: Thursday, February 8, 2018 at 2:14 PM
To: "nfs-ganesha-devel@lists.sourceforge.net" 

Subject: [Nfs-ganesha-devel] New things in feature board

Hello all,

I am trying new things in our project board. Let me know if the approach is 
okay, or you would like to change something.

1. Adding issues in github:
   It seems like only when there is an issue, I can assign it to the developer 
actively working on it. For example, in 2.7 board I have created a issue for 
"FSAL_PSEDUO" reference and assigned to Frank for now (as an example). 
https://github.com/orgs/nfs-ganesha/projects/1
 If you are not planning to work actively on it for this release cycle, feel 
free to move it in backlog or reassign to someone else.

2. New label "should_be_backported"
I have created a new label for our github issue to mark the bug fix that we 
would like to backport for earlier version as well.

3. New board: NFS-Ganesha wish list
   Treat this as a dumping ground for all things that you want but don't have 
time. With increasing community, we new members would be excited to work on 
them. I have added link to Frank's google doc on Ganesha punch list.

4. NFS-Ganesha 2.6 board:
   As NFS-Ganesha 2.6 is feature complete, I am using this board to track if we 
have test coverage and documentation for key features. If not, we can focus on 
adding them.

5. Automation in board:
   I will set rules in board, so that whenever an issue is closed, it moves 
automatically to done.

Thanks,
Supriti
--
Supriti Singh
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

--
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] About referrals in FSAL_VFS

[Sriram Patil]

So, any subfsal for a filesystem which does not support xattrs cannot work with 
the current FSAL_VFS referrals mechanism. Ideally, it would be good to have 
subfsal callbacks, the way we have it for other things in ganesha. It will look 
much better instead of overriding a set of functions declared in subfsal.h. 
But, let’s push this for some other day and keep it open for discussion. I was 
thinking of making this change without doing much changes in the current 
framework. This is what I would like to do,

Add a couple of functions in subfsal.h for allowing subfsals to decide how 
referrals work. For example,

bool vfs_is_referral_handle(struct vfs_fsal_obj_handle *hdl, struct attrlist 
*atrs); - we check for the attributes and file types here to decide whether it 
is a referral

fsal_status_t vfs_fetch_referral_locations(struct vfs_fsal_obj_handle *hdl) – 
read the fs_locations (currently through xattrs) and store them where ever 
desired (currently stored in hdl->u.directory.fs_location)

Add fs_locations callback in vfs_subfsal_obj_ops, to allow subfsals manage the 
fs_locations on their own.

Both these methods will have a default implementation in FSAL_VFS. So, a 
subfsal can keep using the current mechanism.

However, this is not sufficient. The directory and sticky bit referral is also 
checked in nfs4_op_getattr and nfs4_op_readdir. Need to figure out how to get 
rid of that.

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Thursday, February 8, 2018 at 12:24 AM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

If you could share the details of what you want to do differently we can 
discuss the best way to accomplish that.

After the research on what it would take to eliminate sub-FSAL, it’s clear that 
is here to stay, and extending the sub-FSAL API could be the best solution.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, February 7, 2018 7:06 AM
To: nfs-ganesha-devel@lists.sourceforge.net
Subject: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hi,

I understand that we are not supposed to extend subfsals and should move to 
Stackable FSALs. But, since it is not possible in some cases (e.g. 
open_by_handle is not supported by the kernel), subfsal has to stay.

Currently, the referrals decision is made by FSAL_VFS depending on a specific 
set of attributes and user.fs_location xattr value. If a subfsal wants to 
achieve this with some other mechanism, there is no way to do that in the 
current code. So, I wanted to extend the referrals functionality in FSAL_VFS 
and make it more flexible by allowing subfsal to change the behavior or not 
support referrals at all.

Any thoughts?

Thanks,
Sriram

[mage removed by 
sender.]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dicon=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE=Sxe5kPESvRQNVvLQpnj-kS5z4dSATNnBt_o68SJnuLY=s_mPaRcDDkTp9mXMAwNTKTZszaS01QhJt-O3_yMMzHI=>

Virus-free. 
www.avast.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dlink=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE=Sxe5kPESvRQNVvLQpnj-kS5z4dSATNnBt_o68SJnuLY=4Zf0lAj2J05RO-NKkxDvCVKB4dbMDu8cCIjgzNlL1N8=>


--
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] About referrals in FSAL_VFS

[Sriram Patil]

Hi,

I understand that we are not supposed to extend subfsals and should move to 
Stackable FSALs. But, since it is not possible in some cases (e.g. 
open_by_handle is not supported by the kernel), subfsal has to stay.

Currently, the referrals decision is made by FSAL_VFS depending on a specific 
set of attributes and user.fs_location xattr value. If a subfsal wants to 
achieve this with some other mechanism, there is no way to do that in the 
current code. So, I wanted to extend the referrals functionality in FSAL_VFS 
and make it more flexible by allowing subfsal to change the behavior or not 
support referrals at all.

Any thoughts?

Thanks,
Sriram
--
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] pynfs WRT14 failure with timeout

[Sriram Patil]

Hi,

I have been continuously seeing this issue when running pynfs test suite

WRT14st_write.testLargeWrite  : RUNNING
Traceback (most recent call last):
  File "/root/pynfs/nfs4.0/lib/testmod.py", line 222, in run
self.runtest(self, environment)
  File "/root/pynfs/nfs4.0/servertests/st_write.py", line 361, in testLargeWrite
res = c.write_file(fh, 'A'*maxwrite, how=UNSTABLE4)
  File "/root/pynfs/nfs4.0/nfs4lib.py", line 768, in write_file
res = self.compound(ops)
  File "/root/pynfs/nfs4.0/nfs4lib.py", line 333, in compound
res = self.call(NFSPROC4_COMPOUND, p.get_buffer())
  File "/root/pynfs/nfs4.0/lib/rpc/rpc.py", line 411, in call
return self.listen(xid)
  File "/root/pynfs/nfs4.0/lib/rpc/rpc.py", line 360, in listen
reply = self.socket.recv_record()
  File "/root/pynfs/nfs4.0/lib/rpc/rpc.py", line 158, in _recv_record
rec_mark = self.recv_all(4)
  File "/root/pynfs/nfs4.0/lib/rpc/rpc.py", line 145, in _recv_all
newdata = self.recv(n)
timeout: timed out

I see that there was some discussion around this issue on the mailing list, but 
could not find anything conclusive on that thread. My ganesha version is v2.5 
and ntirpc version is 1.5.3. I am running pynfs on an internal fsal (it is 
basically a subfsal and uses most of the code from VFS). Was this issue 
diagnosed and fixed?

Thanks,
Sriram
--
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] [FSAL_VFS] NFSv4 referrals not working

[Sriram Patil]

Yes, the fix looks straight forward. Let me work on it, will submit the review 
soon.

Thanks,
Sriram

From: Frank Filz <ffilz...@mindspring.com>
Date: Wednesday, January 17, 2018 at 8:24 PM
To: Sriram Patil <srir...@vmware.com>, 
"nfs-ganesha-devel@lists.sourceforge.net" 
<nfs-ganesha-devel@lists.sourceforge.net>
Cc: Kamal Charan <kcha...@vmware.com>, Sakthi Kumar <sakt...@vmware.com>
Subject: RE: [Nfs-ganesha-devel] [FSAL_VFS] NFSv4 referrals not working

Ok, I see the issue. In the past, I believe referrals have always been used 
with exports where Path and Pseudo were the same (note that prior to the 
addition of the mount_path_pseudo option, doing otherwise was confusing to NFS 
v3 clients since they would have a different mount path to the export).

I think the solution is simple, before filling in fs_root, we need to check if 
the current export’s Path is different from Pseudo, and if so, replace the 
portion of fs_root that is Path in the string with the Pseudo path.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, January 17, 2018 1:56 AM
To: nfs-ganesha-devel@lists.sourceforge.net
Cc: Kamal Charan <kcha...@vmware.com>; Sakthi Kumar <sakt...@vmware.com>
Subject: [Nfs-ganesha-devel] [FSAL_VFS] NFSv4 referrals not working

Hi,

I was experimenting with NFSv4 referrals recently and I have not been able to 
get it working. I tried this on stable version 2.5, so it has referrals changes 
in VFS code. Here’s what I did,

Server A: Path=/A/real/path; Pseudo=/A/pseudo/path
Server B: Path=/B/real/path; Pseudo=/B/pseudo/path

/A/real/path has a directory named “refer_B”, I made the following changes to 
make it a referral directory

chmod –x refer_B; chmod +t refer_B
setfattr –n user.fs_location –v “:/B/pseudo/path” refer_b

This means, whenever a user tries to step inside “refer_B” directory it should 
be redirected to :/B/pseudo/path.

Now, when client requests fs_locations from server A, it sends the fs_locations 
by reding xattr “user.fs_location”. But, the fs_root is taken from 
obj_hdl->u.directory.path. This is populated in lookup_with_fd function in 
FSAL_VFS. It opens the file from handle and then populates the directory path 
by reading the symlink from “/proc/self/fd”.

In this example, obj_hdl->u.directory.path=”/A/real/path/refer_B”. This is sent 
as fs_root to client. Server will always see the real path because pseudo path 
does not exist.

On the NFS client, it tries to validate the fs_root (named as fs_path in linux 
nfs client). [function: nfs4_validate_fspath]. It creates the full path for 
refer_B from dentry cache, which comes out as “/A/pseudo/path/refer_B”, because 
client only knows the pseudo path. It checks if the fs_root 
(/A/real/path/refer_B) is prefix of “/A/pseudo/path/refer_B”. This check fails 
and we get ENOENT error.

The client logs can be found below,

Jan 17 01:26:36 UbuntuWorker kernel: decode_attr_fs_locations: fsroot:
Jan 17 01:26:36 UbuntuWorker kernel: pathname4: / A / real / path / refer_B
Jan 17 01:26:36 UbuntuWorker kernel: decode_attr_fs_locations: servers:
Jan 17 01:26:36 UbuntuWorker kernel: 
Jan 17 01:26:36 UbuntuWorker kernel: pathname4:
Jan 17 01:26:36 UbuntuWorker kernel: / B / pseudo / path
…….
Jan 17 01:26:36 UbuntuWorker kernel: _nfs4_proc_fs_locations: returned status = 0
Jan 17 01:26:36 UbuntuWorker kernel: nfs_follow_referral: referral at /refer_B
Jan 17 01:26:36 UbuntuWorker kernel: nfs4_validate_fspath: path 
/A/pseudo/path/refer_B does not begin with fsroot /A/real/path/refer_B
Jan 17 01:26:36 UbuntuWorker kernel: nfs_follow_referral: done
Jan 17 01:26:36 UbuntuWorker kernel: nfs_do_refmount: done
Jan 17 01:26:36 UbuntuWorker kernel: RPC:   shutting down nfs client for 

Jan 17 01:26:36 UbuntuWorker kernel: RPC:   
rpc_release_client(880429c73a00)
Jan 17 01:26:36 UbuntuWorker kernel: RPC:   destroying nfs client for 

Jan 17 01:26:36 UbuntuWorker kernel: <-- nfs_d_automount(): error -2
Jan 17 01:26:36 UbuntuWorker kernel: NFS: dentry_delete(/refer_B, 3a00cc)

I see that people have said that referrals work fine with Ganesha FSAL_VFS. Am 
I missing something here?

Thanks,
Sriram

[mage removed by 
sender.]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dicon=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE=FE8NnJB-kH-pJs2Ps5Kb1WDv6BClxtq4kndWHudeWi4=671xriZC2IR0-vFHAcSGSfcnclVK7B_b0Boh7rYPdO4=>

Virus-free. 
www.avast.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dlink=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE=FE8NnJB-kH-pJs2Ps

[Nfs-ganesha-devel] [FSAL_VFS] NFSv4 referrals not working

[Sriram Patil]

Hi,

I was experimenting with NFSv4 referrals recently and I have not been able to 
get it working. I tried this on stable version 2.5, so it has referrals changes 
in VFS code. Here’s what I did,

Server A: Path=/A/real/path; Pseudo=/A/pseudo/path
Server B: Path=/B/real/path; Pseudo=/B/pseudo/path

/A/real/path has a directory named “refer_B”, I made the following changes to 
make it a referral directory

chmod –x refer_B; chmod +t refer_B
setfattr –n user.fs_location –v “:/B/pseudo/path” refer_b

This means, whenever a user tries to step inside “refer_B” directory it should 
be redirected to :/B/pseudo/path.

Now, when client requests fs_locations from server A, it sends the fs_locations 
by reding xattr “user.fs_location”. But, the fs_root is taken from 
obj_hdl->u.directory.path. This is populated in lookup_with_fd function in 
FSAL_VFS. It opens the file from handle and then populates the directory path 
by reading the symlink from “/proc/self/fd”.

In this example, obj_hdl->u.directory.path=”/A/real/path/refer_B”. This is sent 
as fs_root to client. Server will always see the real path because pseudo path 
does not exist.

On the NFS client, it tries to validate the fs_root (named as fs_path in linux 
nfs client). [function: nfs4_validate_fspath]. It creates the full path for 
refer_B from dentry cache, which comes out as “/A/pseudo/path/refer_B”, because 
client only knows the pseudo path. It checks if the fs_root 
(/A/real/path/refer_B) is prefix of “/A/pseudo/path/refer_B”. This check fails 
and we get ENOENT error.

The client logs can be found below,

Jan 17 01:26:36 UbuntuWorker kernel: decode_attr_fs_locations: fsroot:
Jan 17 01:26:36 UbuntuWorker kernel: pathname4: / A / real / path / refer_B
Jan 17 01:26:36 UbuntuWorker kernel: decode_attr_fs_locations: servers:
Jan 17 01:26:36 UbuntuWorker kernel: 
Jan 17 01:26:36 UbuntuWorker kernel: pathname4:
Jan 17 01:26:36 UbuntuWorker kernel: / B / pseudo / path
…….
Jan 17 01:26:36 UbuntuWorker kernel: _nfs4_proc_fs_locations: returned status = 0
Jan 17 01:26:36 UbuntuWorker kernel: nfs_follow_referral: referral at /refer_B
Jan 17 01:26:36 UbuntuWorker kernel: nfs4_validate_fspath: path 
/A/pseudo/path/refer_B does not begin with fsroot /A/real/path/refer_B
Jan 17 01:26:36 UbuntuWorker kernel: nfs_follow_referral: done
Jan 17 01:26:36 UbuntuWorker kernel: nfs_do_refmount: done
Jan 17 01:26:36 UbuntuWorker kernel: RPC:   shutting down nfs client for 

Jan 17 01:26:36 UbuntuWorker kernel: RPC:   
rpc_release_client(880429c73a00)
Jan 17 01:26:36 UbuntuWorker kernel: RPC:   destroying nfs client for 

Jan 17 01:26:36 UbuntuWorker kernel: <-- nfs_d_automount(): error -2
Jan 17 01:26:36 UbuntuWorker kernel: NFS: dentry_delete(/refer_B, 3a00cc)

I see that people have said that referrals work fine with Ganesha FSAL_VFS. Am 
I missing something here?

Thanks,
Sriram
--
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] [GlusterFS] NFsv4 to POSIX ACL conversion

[Sriram Patil]

Hi,

I see that there is NFSv4 ACLs to POSIX ACLs mapping code written in GlusterFS 
FSAL. Since, this is pretty standard code and other FSAls may use it instead of 
duplicating the same code every time, can we move the ACL conversion code to a 
common place in Ganesha? The code is independent of the other GlusterFS code.

Let me know your thoughts.

Thanks,
Sriram
--
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] Weekly meeting link

[sriram patil]

Hi,

Can anyone share the weekly meeting link? I tried the link from github wiki
few weeks back and it did not work for some reason. Also, as far as I know
the weekly meeting timings are 10PM IST every Tuesday. Please let me know
if there is any change in that as well.

Thanks,
Sriram
--
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] [FSAL_VFS] Probable memory leak when deallocating handles

[sriram patil]

Hmm we can use the mdcache. But wanted to store some extra information from
sub fsal. I guess I can do it by allocating more memory in
vfs_sub_alloc_handle with a single malloc call.

Thanks,
Sriram

On 08-Jan-2018 7:43 PM, "Frank Filz" <ffilz...@mindspring.com> wrote:

> Why did you want to have an additional cache? FSAL_MDCACHE already
> provides a cache of essentially every handle (though FSAL_MEM and
> FSAL_PSEUDO maintain some additional caching because those object handles
> cannot be evicted (we should actually beef up mdcache to genuinely prevent
> those handles from being evicted so they don’t have to do additional
> caching work…).
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Sunday, January 7, 2018 11:00 PM
> *To:* nfs-ganesha-devel@lists.sourceforge.net
> *Cc:* kcha...@vmware.com; sakt...@vmware.com
> *Subject:* Re: [Nfs-ganesha-devel] [FSAL_VFS] Probable memory leak when
> deallocating handles
>
>
>
> Hi,
>
>
>
> Sorry for the confusion here. The free should work fine because it is
> contagious memory allocated in single malloc/calloc call.
>
> The problem I wanted to address is, there is no corresponding
> vfs_sub_free_handle for vfs_sub_alloc_handle. I wanted to maintain a cache
> for every handle, once we release the handle the cache entries should also
> be evicted. Because there is no support for vfs_sub_free_handle, the sub
> fsal does not know when is the handle released.
>
>
>
> Also, it is easier if we have a void pointer in vfs_fsal_obj_handle to
> keep sub fsal specific data. This way there is no need of having a separate
> cache in sub fsal.
>
>
>
> Thanks,
>
> Sriram
>
>
>
> On Mon, Jan 8, 2018 at 11:58 AM, sriram patil <spsrirampa...@gmail.com>
> wrote:
>
> Hi,
>
>
>
> I was going through the vfs_fsal_obj_handle workflow. As part of the
> function alloc_handle we allocate the handle with the help of
> vfs_sub_alloc_handle.
>
>
>
> vfs_sub_alloc_handle allocates vfs_fsal_obj_handle and vfs_file_handle_t
> back to back. And when releasing the handle (obj_ops->release), it calls
> free on the vfs_fsal_obj_handle. So, when is vfs_file_handle_t freed? Am I
> missing something here?
>
>
>
> Thanks,
>
> Sriram
>
>
>
>
> --
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
> <#m_-432962764810679348_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
--
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] [FSAL_VFS] Probable memory leak when deallocating handles

[sriram patil]

Hi,

Sorry for the confusion here. The free should work fine because it is
contagious memory allocated in single malloc/calloc call.

The problem I wanted to address is, there is no corresponding
vfs_sub_free_handle for vfs_sub_alloc_handle. I wanted to maintain a cache
for every handle, once we release the handle the cache entries should also
be evicted. Because there is no support for vfs_sub_free_handle, the sub
fsal does not know when is the handle released.

Also, it is easier if we have a void pointer in vfs_fsal_obj_handle to keep
sub fsal specific data. This way there is no need of having a separate
cache in sub fsal.

Thanks,
Sriram

On Mon, Jan 8, 2018 at 11:58 AM, sriram patil <spsrirampa...@gmail.com>
wrote:

> Hi,
>
> I was going through the vfs_fsal_obj_handle workflow. As part of the
> function alloc_handle we allocate the handle with the help of
> vfs_sub_alloc_handle.
>
> vfs_sub_alloc_handle allocates vfs_fsal_obj_handle and vfs_file_handle_t
> back to back. And when releasing the handle (obj_ops->release), it calls
> free on the vfs_fsal_obj_handle. So, when is vfs_file_handle_t freed? Am I
> missing something here?
>
> Thanks,
> Sriram
>
--
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] [FSAL_VFS] Probable memory leak when deallocating handles

[sriram patil]

Hi,

I was going through the vfs_fsal_obj_handle workflow. As part of the
function alloc_handle we allocate the handle with the help of
vfs_sub_alloc_handle.

vfs_sub_alloc_handle allocates vfs_fsal_obj_handle and vfs_file_handle_t
back to back. And when releasing the handle (obj_ops->release), it calls
free on the vfs_fsal_obj_handle. So, when is vfs_file_handle_t freed? Am I
missing something here?

Thanks,
Sriram
--
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] Subfsal export

[sriram patil]

Thanks for the help Frank and Daniel. I figured it is much easy to enable
"mount_path_pseudo" and use pseudo path instead of using symlinks. No code
changes required. The sole purpose was to hide the original path because it
is long or cryptic.

Thanks,
Sriram

On Fri, Nov 10, 2017 at 6:58 PM, Daniel Gryniewicz <d...@redhat.com> wrote:

> You can do this with a stackable FSAL, since it's on top, not underneath,
> so it can override anything you want.  You can even just put the symlink
> part in your FSAL, and defer everything else so VFS, if you want.
>
> Daniel
>
> On 11/08/2017 03:04 PM, Frank Filz wrote:
>
>> Yea, in the case of wanting to allow symlink exports, you would need to
>> replace the method. I’d be interested in why you want to allow them. That
>> is something that actually could be handled by a config or compile option.
>>
>> Frank
>>
>> *From:*sriram patil [mailto:spsrirampa...@gmail.com]
>> *Sent:* Wednesday, November 8, 2017 10:20 AM
>> *To:* Frank Filz <ffilz...@mindspring.com>
>> *Cc:* d...@redhat.com; nfs-ganesha-devel@lists.sourceforge.net
>> *Subject:* Re: [Nfs-ganesha-devel] Subfsal export
>>
>> Hi,
>>
>> In case of stackable FSALs, what if I want the underlying FSAL behave
>> differently. For example, VFS does not allow symlink exports, lookup_path
>> fails if we try to export symlink pointing to a directory. There can be
>> such cases where I want to defer (very small changes) from the underlying
>> "sub fsal". For bypassing some part of the underlying fsal function, is
>> rewriting the function the only way?
>>
>> Thanks,
>>
>> Sriram
>>
>> On Wed, Nov 8, 2017 at 11:22 PM, sriram patil <spsrirampa...@gmail.com
>> <mailto:spsrirampa...@gmail.com>> wrote:
>>
>> Hmm stackable FSAL sounds like a good option. Let me investigate on
>> that. I was mainly going with sub fsal because of xfs.
>>
>> I agree with both of you about pushing FSAL changes to upstream. Let
>> me see if I can make that happen.
>>
>> Thanks,
>>
>> Sriram
>>
>> On 08-Nov-2017 11:03 PM, "Frank Filz" <ffilz...@mindspring.com
>> <mailto:ffilz...@mindspring.com>> wrote:
>>
>>  > You might want to consider a stackable FSAL instead.
>>  FSAL_NULL is a good
>>  > example to start from.  It's much more flexible than
>> sub_fsals for VFS.
>> If I
>>  > was implementing PanFS now, I'd use a stackable FSAL instead.
>>
>> Yea, this is a good point. Probably even the XFS/VFS split
>> should be done
>> with stackable FSAL.
>>
>>  > Ganesha is LGPL specifically to allow non-FOSS FSALs.
>>  However, if the
>> FSAL
>>  > itself does not require proprietary code, there are many
>> advantages to
>> open
>>  > sourcing it and getting it upstream.  Not the least is that
>> changes to
>> APIs and
>>  > the build system will be fixed by the community, so there
>> will be fewer
>> cases
>>  > of sudden breakage for you to fix.
>>
>> On top of direct API impacts, it also helps to understand how
>> other FSALs
>> are using Ganesha so that not only do we not break the API, but
>> don't break
>> other assumptions that were made. It also is a better platform for
>> requesting FSAL specific API accommodation (for a recent
>> example, see
>> compute_readdir_cookie and whence_is_name support that was added
>> for
>> FSAL_RGW, though added in a generic way so other FSALs might use
>> it).
>>
>> Frank
>>
>>  > Daniel
>>  >
>>  > On 11/08/2017 10:51 AM, sriram patil wrote:
>>  > > Yes, I am making a new sub fsal. May not push it to
>> upstream because
>>  > > it will not be useful without the whole framework/product.
>> As part of
>>  > > that, I wanted to allocate an export object which has some
>> extra
>>  > > fields, other than the ones in vfs_fsal_export.
>>  > >
>>  > > Also, I hope creating a sub fsal and not making the
>> implementation
>>  > > opensource does not violate any license terms.
>>  > >

Re: [Nfs-ganesha-devel] Subfsal export

[sriram patil]

Hi,

In case of stackable FSALs, what if I want the underlying FSAL behave
differently. For example, VFS does not allow symlink exports, lookup_path
fails if we try to export symlink pointing to a directory. There can be
such cases where I want to defer (very small changes) from the underlying
"sub fsal". For bypassing some part of the underlying fsal function, is
rewriting the function the only way?

Thanks,
Sriram


On Wed, Nov 8, 2017 at 11:22 PM, sriram patil <spsrirampa...@gmail.com>
wrote:

> Hmm stackable FSAL sounds like a good option. Let me investigate on that.
> I was mainly going with sub fsal because of xfs.
>
> I agree with both of you about pushing FSAL changes to upstream. Let me
> see if I can make that happen.
>
> Thanks,
> Sriram
>
> On 08-Nov-2017 11:03 PM, "Frank Filz" <ffilz...@mindspring.com> wrote:
>
>> > You might want to consider a stackable FSAL instead.  FSAL_NULL is a
>> good
>> > example to start from.  It's much more flexible than sub_fsals for VFS.
>> If I
>> > was implementing PanFS now, I'd use a stackable FSAL instead.
>>
>> Yea, this is a good point. Probably even the XFS/VFS split should be done
>> with stackable FSAL.
>>
>> > Ganesha is LGPL specifically to allow non-FOSS FSALs.  However, if the
>> FSAL
>> > itself does not require proprietary code, there are many advantages to
>> open
>> > sourcing it and getting it upstream.  Not the least is that changes to
>> APIs and
>> > the build system will be fixed by the community, so there will be fewer
>> cases
>> > of sudden breakage for you to fix.
>>
>> On top of direct API impacts, it also helps to understand how other FSALs
>> are using Ganesha so that not only do we not break the API, but don't
>> break
>> other assumptions that were made. It also is a better platform for
>> requesting FSAL specific API accommodation (for a recent example, see
>> compute_readdir_cookie and whence_is_name support that was added for
>> FSAL_RGW, though added in a generic way so other FSALs might use it).
>>
>> Frank
>>
>> > Daniel
>> >
>> > On 11/08/2017 10:51 AM, sriram patil wrote:
>> > > Yes, I am making a new sub fsal. May not push it to upstream because
>> > > it will not be useful without the whole framework/product. As part of
>> > > that, I wanted to allocate an export object which has some extra
>> > > fields, other than the ones in vfs_fsal_export.
>> > >
>> > > Also, I hope creating a sub fsal and not making the implementation
>> > > opensource does not violate any license terms.
>> > >
>> > > Thanks,
>> > > Sriram
>> > >
>> > > On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz" <d...@redhat.com
>> > > <mailto:d...@redhat.com>> wrote:
>> > >
>> > > On 11/08/2017 02:41 AM, sriram patil wrote:
>> > >
>> > > Hi,
>> > >
>> > > In the subfsal framework, I see that subfsals can have their
>> own
>> > > fsal_obj_handles by implementing vfs_sub_alloc_handle and then
>> > > use subfsal specific variables using container_of.
>> > >
>> > > It does not provide same functionality for fsal_export
>> however.
>> > > There is no vfs_sub_alloc_export.  vfs_create_export just
>> calls
>> > > gsh_calloc to allocate vfs_fsal_export, giving no flexibility.
>> > >
>> > > PANFS has its own struct panfs_fsal_export but it is not
>> > > allocated anywhere. It still uses container_of on
>> > > vfs_fsal_export. This looks like a memory corruption. The last
>> > > commit in PANFS however is about a year back, not sure if it
>> is
>> > > actively developed.
>> > >
>> > >
>> > > PANFS is unused and unmaintained.  We keep it building, but that's
>> it.
>> > >
>> > > Considering the above scenario, it makes sense to have
>> > > vfs_sub_alloc_export to allow allocating the wrapper export
>> > > object. Any thoughts?
>> > >
>> > >
>> > > This seems like it was a bug in the original implementation for
>> > > PanFS. It probably should be fixed, but the VFS sub_fsal doesn't
>> > > need it, so it works for now.
>> > >
>> > > Are you making a new sub_fsal?

Re: [Nfs-ganesha-devel] Subfsal export

[sriram patil]

Hmm stackable FSAL sounds like a good option. Let me investigate on that. I
was mainly going with sub fsal because of xfs.

I agree with both of you about pushing FSAL changes to upstream. Let me see
if I can make that happen.

Thanks,
Sriram

On 08-Nov-2017 11:03 PM, "Frank Filz" <ffilz...@mindspring.com> wrote:

> > You might want to consider a stackable FSAL instead.  FSAL_NULL is a good
> > example to start from.  It's much more flexible than sub_fsals for VFS.
> If I
> > was implementing PanFS now, I'd use a stackable FSAL instead.
>
> Yea, this is a good point. Probably even the XFS/VFS split should be done
> with stackable FSAL.
>
> > Ganesha is LGPL specifically to allow non-FOSS FSALs.  However, if the
> FSAL
> > itself does not require proprietary code, there are many advantages to
> open
> > sourcing it and getting it upstream.  Not the least is that changes to
> APIs and
> > the build system will be fixed by the community, so there will be fewer
> cases
> > of sudden breakage for you to fix.
>
> On top of direct API impacts, it also helps to understand how other FSALs
> are using Ganesha so that not only do we not break the API, but don't break
> other assumptions that were made. It also is a better platform for
> requesting FSAL specific API accommodation (for a recent example, see
> compute_readdir_cookie and whence_is_name support that was added for
> FSAL_RGW, though added in a generic way so other FSALs might use it).
>
> Frank
>
> > Daniel
> >
> > On 11/08/2017 10:51 AM, sriram patil wrote:
> > > Yes, I am making a new sub fsal. May not push it to upstream because
> > > it will not be useful without the whole framework/product. As part of
> > > that, I wanted to allocate an export object which has some extra
> > > fields, other than the ones in vfs_fsal_export.
> > >
> > > Also, I hope creating a sub fsal and not making the implementation
> > > opensource does not violate any license terms.
> > >
> > > Thanks,
> > > Sriram
> > >
> > > On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz" <d...@redhat.com
> > > <mailto:d...@redhat.com>> wrote:
> > >
> > > On 11/08/2017 02:41 AM, sriram patil wrote:
> > >
> > > Hi,
> > >
> > > In the subfsal framework, I see that subfsals can have their
> own
> > > fsal_obj_handles by implementing vfs_sub_alloc_handle and then
> > > use subfsal specific variables using container_of.
> > >
> > > It does not provide same functionality for fsal_export however.
> > > There is no vfs_sub_alloc_export.  vfs_create_export just calls
> > > gsh_calloc to allocate vfs_fsal_export, giving no flexibility.
> > >
> > > PANFS has its own struct panfs_fsal_export but it is not
> > > allocated anywhere. It still uses container_of on
> > > vfs_fsal_export. This looks like a memory corruption. The last
> > > commit in PANFS however is about a year back, not sure if it is
> > > actively developed.
> > >
> > >
> > > PANFS is unused and unmaintained.  We keep it building, but that's
> it.
> > >
> > > Considering the above scenario, it makes sense to have
> > > vfs_sub_alloc_export to allow allocating the wrapper export
> > > object. Any thoughts?
> > >
> > >
> > > This seems like it was a bug in the original implementation for
> > > PanFS. It probably should be fixed, but the VFS sub_fsal doesn't
> > > need it, so it works for now.
> > >
> > > Are you making a new sub_fsal?
> > >
> > > Daniel
> > >
> > >
> 
> 
> --
> > > 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
> > > <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
> > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> > > <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel>
> > >
> >
> >
> >
> 
> 
> --
> > Check out the vibrant 

Re: [Nfs-ganesha-devel] Subfsal export

[sriram patil]

Yes, I am making a new sub fsal. May not push it to upstream because it
will not be useful without the whole framework/product. As part of that, I
wanted to allocate an export object which has some extra fields, other than
the ones in vfs_fsal_export.

Also, I hope creating a sub fsal and not making the implementation
opensource does not violate any license terms.

Thanks,
Sriram

On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz" <d...@redhat.com> wrote:

> On 11/08/2017 02:41 AM, sriram patil wrote:
>
>> Hi,
>>
>> In the subfsal framework, I see that subfsals can have their own
>> fsal_obj_handles by implementing vfs_sub_alloc_handle and then use subfsal
>> specific variables using container_of.
>>
>> It does not provide same functionality for fsal_export however. There is
>> no vfs_sub_alloc_export.  vfs_create_export just calls gsh_calloc to
>> allocate vfs_fsal_export, giving no flexibility.
>>
>> PANFS has its own struct panfs_fsal_export but it is not allocated
>> anywhere. It still uses container_of on vfs_fsal_export. This looks like a
>> memory corruption. The last commit in PANFS however is about a year back,
>> not sure if it is actively developed.
>>
>
> PANFS is unused and unmaintained.  We keep it building, but that's it.
>
> Considering the above scenario, it makes sense to have
>> vfs_sub_alloc_export to allow allocating the wrapper export object. Any
>> thoughts?
>>
>
> This seems like it was a bug in the original implementation for PanFS. It
> probably should be fixed, but the VFS sub_fsal doesn't need it, so it works
> for now.
>
> Are you making a new sub_fsal?
>
> Daniel
>
> 
> --
> 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] NLM locks recovery issue

[sriram patil]

One more doubt on this, because I am still not sure why ganesha cannot call
SM_NOTIFY, the way it calls SM_MON, SM_UNMON, etc.

Why can't we bump up the state number and call SM_NOTIFY (or just call
SM_SIMU_CRASH which is combination of the two ops) on local rpc.statd every
time we start ganesha? This will ask statd to send notify messages to all
the clients explicitly. If the monitored client list is empty (first
start), no notifications will be sent. If there are any clients in the
list, they will be notified. If the client does not have server in the
monitored list or the lock is not in the client cache, the notify signal
will be ignored, otherwise it will try to reclaim the lock.

- Sriram

On Tue, Oct 17, 2017 at 9:59 PM, sriram patil <spsrirampa...@gmail.com>
wrote:

> Ohh okay. Thanks for the help Frank and Malahal. I will look into this
> further. I will update on this once I get everything working.
>
> - Sriram
>
> On Tue, Oct 17, 2017 at 7:22 PM, Frank Filz <ffilz...@mindspring.com>
> wrote:
>
>> Yes, good point. That SHOULD all be covered by the scripting. To be
>> honest, I haven’t actually looked at the various sample scripts, for
>> development, I run a modified init.d script from the Ganesha 1.5 timeframe…
>>
>>
>>
>> I think sm-notify –f does update the NSM state number.
>>
>>
>>
>> Frank
>>
>>
>>
>> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
>> *Sent:* Monday, October 16, 2017 11:02 PM
>> *To:* Frank Filz <ffilz...@mindspring.com>
>> *Cc:* Malahal Naineni <mala...@gmail.com>; nfs-ganesha-devel@lists.source
>> forge.net
>>
>> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>>
>>
>>
>> Even with this, unless we can change the rpc.statd state, the SM_NOTIFY
>> will not trigger any lock reclaims on the client side. I know the state
>> number should be even/odd depending on whether the server is down/up. Is it
>> safe to change the state number manually and then run sm_notify.ganesha?
>> How can one guarantee the NSM/NLM semantics in case of server crash in the
>> current scenario?
>>
>>
>>
>> On Tue, Oct 17, 2017 at 12:37 AM, Frank Filz <ffilz...@mindspring.com>
>> wrote:
>>
>> The model of rpc.statd is that the client talks to its rpc.statd and the
>> server talks to its rpc.statd, and the two rpc.statd talk to each other… So
>> the sm_notify utility is used outside Ganesha essentially as part of
>> rpc.statd to send the SM_NOTIFY requests. Theoretically, the server host
>> should send SM_NOTIFY on reboot, of course since Ganesha is user space, it
>> can crash without a server reboot.
>>
>>
>>
>> There has been some discussion about pulling rpc.statd into Ganesha which
>> would have some advantages and then it would make sense for Ganesha to
>> issue the SM_NOTIFY.
>>
>>
>>
>> Note that sm_notify queries a directory created and managed by rpc.statd.
>> Ganesha does not manage the directory that persists the NLM client
>> information.
>>
>>
>>
>> Frank
>>
>>
>>
>> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
>> *Sent:* Monday, October 16, 2017 11:32 AM
>> *To:* Malahal Naineni <mala...@gmail.com>
>> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
>> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>>
>>
>>
>> Hi,
>>
>>
>>
>> I had a follow up question on this. I was looking into NSM related
>> implementation as well. I see that ganesha handles the notify messages from
>> clients and releases all the locks. But, when the server crashes/restarts
>> it does not explicitly notify clients. I did not find any code sending
>> SM_NOTIFY.
>>
>>
>>
>> There is a separate binary, sm_notify.ganesha, but I am not sure why is
>> it a separate binary instead of making a clnt_call with SM_NOTIFY.
>>
>>
>>
>> There are respectives functions in nsm.h for every NSM proc, but
>> nsm_notify is not implemented.
>>
>>
>>
>> Is this handled in some other way? Are the service scripts supposed to
>> use sm_notify.fanesha binary in some way or it is just test code?
>>
>>
>>
>> Thanks,
>>
>> Sriram
>>
>>
>>
>> On 16-Oct-2017 11:55 PM, "sriram patil" <spsrirampa...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> On 16-Oct-2017 12:50 PM, "Malahal Naineni" <mala...@gmail.com> wrote:
>>
>> NFSv3 protocol doesn't deal with locks, so there is no ment

Re: [Nfs-ganesha-devel] NLM locks recovery issue

[sriram patil]

Ohh okay. Thanks for the help Frank and Malahal. I will look into this
further. I will update on this once I get everything working.

- Sriram

On Tue, Oct 17, 2017 at 7:22 PM, Frank Filz <ffilz...@mindspring.com> wrote:

> Yes, good point. That SHOULD all be covered by the scripting. To be
> honest, I haven’t actually looked at the various sample scripts, for
> development, I run a modified init.d script from the Ganesha 1.5 timeframe…
>
>
>
> I think sm-notify –f does update the NSM state number.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Monday, October 16, 2017 11:02 PM
> *To:* Frank Filz <ffilz...@mindspring.com>
> *Cc:* Malahal Naineni <mala...@gmail.com>; nfs-ganesha-devel@lists.
> sourceforge.net
>
> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>
>
>
> Even with this, unless we can change the rpc.statd state, the SM_NOTIFY
> will not trigger any lock reclaims on the client side. I know the state
> number should be even/odd depending on whether the server is down/up. Is it
> safe to change the state number manually and then run sm_notify.ganesha?
> How can one guarantee the NSM/NLM semantics in case of server crash in the
> current scenario?
>
>
>
> On Tue, Oct 17, 2017 at 12:37 AM, Frank Filz <ffilz...@mindspring.com>
> wrote:
>
> The model of rpc.statd is that the client talks to its rpc.statd and the
> server talks to its rpc.statd, and the two rpc.statd talk to each other… So
> the sm_notify utility is used outside Ganesha essentially as part of
> rpc.statd to send the SM_NOTIFY requests. Theoretically, the server host
> should send SM_NOTIFY on reboot, of course since Ganesha is user space, it
> can crash without a server reboot.
>
>
>
> There has been some discussion about pulling rpc.statd into Ganesha which
> would have some advantages and then it would make sense for Ganesha to
> issue the SM_NOTIFY.
>
>
>
> Note that sm_notify queries a directory created and managed by rpc.statd.
> Ganesha does not manage the directory that persists the NLM client
> information.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Monday, October 16, 2017 11:32 AM
> *To:* Malahal Naineni <mala...@gmail.com>
> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>
>
>
> Hi,
>
>
>
> I had a follow up question on this. I was looking into NSM related
> implementation as well. I see that ganesha handles the notify messages from
> clients and releases all the locks. But, when the server crashes/restarts
> it does not explicitly notify clients. I did not find any code sending
> SM_NOTIFY.
>
>
>
> There is a separate binary, sm_notify.ganesha, but I am not sure why is it
> a separate binary instead of making a clnt_call with SM_NOTIFY.
>
>
>
> There are respectives functions in nsm.h for every NSM proc, but
> nsm_notify is not implemented.
>
>
>
> Is this handled in some other way? Are the service scripts supposed to use
> sm_notify.fanesha binary in some way or it is just test code?
>
>
>
> Thanks,
>
> Sriram
>
>
>
> On 16-Oct-2017 11:55 PM, "sriram patil" <spsrirampa...@gmail.com> wrote:
>
>
>
>
>
> On 16-Oct-2017 12:50 PM, "Malahal Naineni" <mala...@gmail.com> wrote:
>
> NFSv3 protocol doesn't deal with locks, so there is no mention of grace
> period. NLM protocol is used in NFSv3 environments, so grace period does
> exist in NLM.
>
>
>
> >> So, NFSv3 only server will mostly run with "Graceless = true"
>
>
>
> The above is true if you run ganesha with NFSv3 and disable NLM. This is
> not the usual case! We do run with NLM enabled, so we have grace period
> defined even in our NFSv3 only environments.
>
>
>
> Okay. So, NFSv4 grace period is used for NLM in case of NFSv3. The
> nlm_grace_tv confused me. Thanks for clarifying.
>
>
>
>
>
> >> So, nfs4_Lock should actually use the NLM server grace period
>
>
>
> You mean nlm4_Lock?  I don't see a separate NLM grace period in
> ganesha. nlm_grace_tv seems to be just grace time (not period).  It should
> be removed as it is NOT used at all.
>
>
>
> True. Will send this patch.
>
>
>
>
>
> Regards, Malahal.
>
>
>
>
>
> On Mon, Oct 16, 2017 at 11:35 AM, sriram patil <spsrirampa...@gmail.com>
> wrote:
>
> Hi,
>
> I was looking into NLM locking code for NFSv3. According to NLM/NSM
> protocols specifications, when server restarts, the client should send
> 

Re: [Nfs-ganesha-devel] NLM locks recovery issue

[sriram patil]

Hi,

I had a follow up question on this. I was looking into NSM related
implementation as well. I see that ganesha handles the notify messages from
clients and releases all the locks. But, when the server crashes/restarts
it does not explicitly notify clients. I did not find any code sending
SM_NOTIFY.

There is a separate binary, sm_notify.ganesha, but I am not sure why is it
a separate binary instead of making a clnt_call with SM_NOTIFY.

There are respectives functions in nsm.h for every NSM proc, but nsm_notify
is not implemented.

Is this handled in some other way? Are the service scripts supposed to use
sm_notify.fanesha binary in some way or it is just test code?

Thanks,
Sriram

On 16-Oct-2017 11:55 PM, "sriram patil" <spsrirampa...@gmail.com> wrote:

>
>
> On 16-Oct-2017 12:50 PM, "Malahal Naineni" <mala...@gmail.com> wrote:
>
> NFSv3 protocol doesn't deal with locks, so there is no mention of grace
> period. NLM protocol is used in NFSv3 environments, so grace period does
> exist in NLM.
>
> >> So, NFSv3 only server will mostly run with "Graceless = true"
>
> The above is true if you run ganesha with NFSv3 and disable NLM. This is
> not the usual case! We do run with NLM enabled, so we have grace period
> defined even in our NFSv3 only environments.
>
>
> Okay. So, NFSv4 grace period is used for NLM in case of NFSv3. The
> nlm_grace_tv confused me. Thanks for clarifying.
>
>
> >> So, nfs4_Lock should actually use the NLM server grace period
>
> You mean nlm4_Lock?  I don't see a separate NLM grace period in
> ganesha. nlm_grace_tv seems to be just grace time (not period).  It should
> be removed as it is NOT used at all.
>
>
> True. Will send this patch.
>
>
> Regards, Malahal.
>
>
> On Mon, Oct 16, 2017 at 11:35 AM, sriram patil <spsrirampa...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I was looking into NLM locking code for NFSv3. According to NLM/NSM
>> protocols specifications, when server restarts, the client should send
>> nlm4_Lock request with "reclaim" flag set. This reclaim is honored
>> only if "NLM server" is in grace period. However, this code in
>> nlm4_Lock function actually looks if the NFS server is in grace
>> period, instead of checking NLM server.
>>
>> Also, NLM is used in case of NFSv3 and NFSv3 specs do not define grace
>> period. So, NFSv3 only server will mostly run with "Graceless = true"
>> and the lock recovery will not work on server restarts.
>>
>> So, nfs4_Lock should actually use the NLM server grace period
>> (nlm_grace_tv) for handling reclaims. Since NFSv4 does not use NLM at
>> all, we can assume that NLM code path is useful only for NFSv3.
>>
>> Does this look like a genuine issue?
>>
>> Thanks,
>> Sriram
>>
>> 
>> --
>> 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] NLM locks recovery issue

[sriram patil]

Hi,

I was looking into NLM locking code for NFSv3. According to NLM/NSM
protocols specifications, when server restarts, the client should send
nlm4_Lock request with "reclaim" flag set. This reclaim is honored
only if "NLM server" is in grace period. However, this code in
nlm4_Lock function actually looks if the NFS server is in grace
period, instead of checking NLM server.

Also, NLM is used in case of NFSv3 and NFSv3 specs do not define grace
period. So, NFSv3 only server will mostly run with "Graceless = true"
and the lock recovery will not work on server restarts.

So, nfs4_Lock should actually use the NLM server grace period
(nlm_grace_tv) for handling reclaims. Since NFSv4 does not use NLM at
all, we can assume that NLM code path is useful only for NFSv3.

Does this look like a genuine issue?

Thanks,
Sriram

--
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] Multi instance Ganesha with DBus

[sriram patil]

I am running ganesha inside docker containers. I have tried to run dbus
inside docker, but that fails because system_bus_socket does not exist.
This is the actual problem.

To solve this, I am using the host dbus server from containers by mounting
the host system_bus_socket inside the containers. So, all ganesha servers
will register with the host dbus. This is why I need different bus names
for every ganesha server running inside containers.

Thanks,
Sriram

On 03-Oct-2017 5:35 PM, "Daniel Gryniewicz" <d...@redhat.com> wrote:

> On 10/03/2017 02:31 AM, sriram patil wrote:
>
>> Hi,
>>
>> AFAIK we can run only single instance of nfs-ganesha on a given
>> machine which supports dbus signals. Running with different ports, nfs
>> ganesha service comes up, but the dbus signals work only for the first
>> (primary) instance. We cannot interact with the ganesha instances
>> (other than primary) through dbus. This is a big deal, because dynamic
>> exports, runtime grace periods, stats, etc are not available on
>> "secondary" ganesha instances.
>>
>> I wanted to know if this is an issue at all? And is there anyone
>> working on this already?
>>
>> Of the top of my head, I am thinking of handling this by adding an
>> identifier configuration which can be appended to the bus name. For
>> example, org.ganesha.nfsd.id1, org.ganesha.nfsd.id2, etc. Any
>> suggestions on this approach? Can we handle it in a better way?
>>
>>
> Just out of curiosity, what's the use-case for multiple Ganesha's on the
> same machine, as opposed to just putting all the exports on the same
> Ganesha?
>
> Daniel
>
> 
> --
> 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] Multi instance Ganesha with DBus

[sriram patil]

Hi,

AFAIK we can run only single instance of nfs-ganesha on a given
machine which supports dbus signals. Running with different ports, nfs
ganesha service comes up, but the dbus signals work only for the first
(primary) instance. We cannot interact with the ganesha instances
(other than primary) through dbus. This is a big deal, because dynamic
exports, runtime grace periods, stats, etc are not available on
"secondary" ganesha instances.

I wanted to know if this is an issue at all? And is there anyone
working on this already?

Of the top of my head, I am thinking of handling this by adding an
identifier configuration which can be appended to the bus name. For
example, org.ganesha.nfsd.id1, org.ganesha.nfsd.id2, etc. Any
suggestions on this approach? Can we handle it in a better way?

Thanks,
Sriram

--
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] Moving from 2.3 to 2.4

[sriram patil]

Hi,

We have been working with 2.3-stable release for a while now. We have
stabilised our FSAl layer recently and wanted to move to 2.4. I can
see that there are a lot of design changes as well which went into
2.4. How is the FSAL layer impacted with these changes? Are there any
semantic changes?

Also, the extended support functions seem to be optional. So, is it a
major impact on FSAL layer if support_ex callbacks are not
implemented?

Thanks,
Sriram

--
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] Consistently hitting OOM killer

[sriram patil]

Hi,

We have been able to reproduce the OOM killer error consistently. NFS
Ganesha memory consumption goes as high as 85-90 gigs (>60% of total
memory). The test case is very simple,
just keep creating files (with dd, bs=64k count=1).

The setup has 1 NFS Ganesha server and 8 clients which are
continuously firing dds. After about 1M files, the memory reaches to
85 gigs. Which is like every inode consuming 85k of memory.

I see that there are already a couple of issues opened on glusterfs,

https://bugzilla.redhat.com/show_bug.cgi?id=1240172
https://bugzilla.redhat.com/show_bug.cgi?id=1337867

Is this a known issue for nfs-ganesha? Can we work around this problem
with some inode cache configuration (cache size, entries hw, cache
fds, etc)?

Thanks,
Sriram

--
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] OP_OPEN does not seem to follow POSIX semantics in case of create

[sriram patil]

Hi,

According to POSIX semantics, when open is does with O_CREAT and
O_EXCL then it should return EEXIST. But, ganesha always expects fsal
layer to return EEXIST from create if the file already exists. This is
handled in cache_inode_create. If fsal create returns EEXIST then
ganesha does a lookup and checks for the type of file and then returns
the entry if the type matches.

On the other hand, if fsal create does not return error even if the
file exists (non O_EXCL semantics), ganesha goes ahead and tries to
add a directory entry (cache_inode_add_cached_dirent), which returns
CACHE_INODE_ENTRY_EXISTS and create fails!

A simple way to reproduce this is, mount same export on two different
clients and do the following steps to reproduce.

client1:/mnt> echo abc > testfile
client2:/mnt> echo abc > testfile
bash: testfile: File exists

I think ganesha should ignore the return status of
cache_inode_add_cached_dirent if it is CACHE_INODE_ENTRY_EXISTS (This
is already done in cache_inode_lookup_impl). This way the EEXIST error
will not be propagated to nfs-client.

Thanks,
Sriram

--
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] ganesha config editor user interface thoughts

[sriram patil]

Hi Malahal,

Can we have the key value pairs as options to the commands? For example,

ganesha_config add export path --pseudo  --protocols 4
--access RW --exportid 30

This way the block can be setup in a single command. Also, one does not
have to worry about the exact key and cases (like Export_id).

But, the line of code will increase for sure.

Thanks,
Sriram


On Sun, Feb 26, 2017 at 9:26 AM, Frank Filz  wrote:

> There are Sind empty blocks such as log components can be empty.
>
> Sent from my iPhone
>
> > On Feb 25, 2017, at 7:20 PM, Malahal Naineni  wrote:
> >
> > Assuming that there is no point in creating empty blocks, then we can
> > just have "set" and "del" commands. The "set" command's last two
> > arguments are always "key, value" pairs.
> >
> > ganesha_conf set block [subblocks] key value
> > ganesha_conf del block [subblocks] [key]
> >
> > We might need a show command  to complement this as well.
> >
> >> On Sat, Feb 25, 2017 at 3:33 PM, Malahal Naineni 
> wrote:
> >> Hi All, As as I said last week, here are my thoughts on command line
> >> interface to edit ganesha config. Appreciate any thoughts on this.
> >>
> >> Observations:
> >>
> >> - All config is in blocks
> >> - Most blocks are unique with their tag names
> >>  - exceptions: "export" and "client" blocks.
> >>  - "export" is unique by "path" value
> >>  - "client" is unique by "clients" value with in the export block.
> >> - Log blocks have few subblocks.
> >> - Blocks contain a list of key value pairs and possibly some subblocks.
> >>
> >> Commands to create a block/subblock
> >> (block and subblock names should be validated)
> >>
> >> ganesha_config add blockname
> >> ganesha_config add log [subblocks]
> >> ganesha_config add export path
> >> ganesha_config add export path client clients
> >>
> >> Add, delete, modify a key value pair in a block/subblock
> >> (key and values need to be validated)
> >>
> >> ganehsa_config mod blockname key value
> >> ganesha_config mod log [sub-blocks] key value
> >> ganesha_config mod export path key value
> >> ganehsa_config mod export path client clients key value
> >>
> >> Absence of "value" will delete the key itself from the block. This
> means "key"
> >> name can't be a subblock name. Is this true today and want to preserve
> this
> >> behavior? Otherwise, we will have to use "delete" as a special reserved
> >> value to delete a key. Any thoughts?
> >>
> >>
> >> Commands to delete a block/subblock (same as their "add" counter parts)
> >>
> >> ganesha_config del blockname
> >> ganesha_config del log [subblocks]
> >> ganesha_config del export path
> >> ganesha_config del export path client clients
> >
> > 
> --
> > 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
>
--
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] Why FATTR4_ARCHIVE does not have decode method?

[sriram patil]

Is there any NFSv4 Windows client that works with ganesha?

Thanks,
Sriram

On Thu, Feb 23, 2017 at 10:57 PM, Frank Filz <ffilz...@mindspring.com>
wrote:

> Hmm, I don’t think Ganesha advertises support for FATTR4_ARCHIVE, so
> client SHOULD NOT be sending it.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Thursday, February 23, 2017 9:22 AM
> *To:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* [Nfs-ganesha-devel] Why FATTR4_ARCHIVE does not have decode
> method?
>
>
>
> Hi,
>
>
>
> I was trying to use NFS Ganesha NFSv4 export using a windows client. But
> this windows client is sending FATTR4_ARCHIVE in createattrs as part of
> OPEN and fails to create any file.
>
>
>
> decode method for FATTR4_ARCHIVE is not implemented, it returns NOOP. I
> figured that the read-only attributes do not need a decode method, but
> FATTR4_ARCHIVE is a read-write attribute according to RFCs (3530 and 5661).
> Is there any specific reason decode is not implemented for archive?
>
>
>
> Also, I am not sure if there is any official windows client for NFSv4, I
> was using the one published by cohortfs. Is there some other windows client
> with which NFS Ganesha works seamlessly?
>
>
>
> Thanks,
>
> Sriram
>
>
> --
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <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] Why FATTR4_ARCHIVE does not have decode method?

[sriram patil]

Hi,

I was trying to use NFS Ganesha NFSv4 export using a windows client. But
this windows client is sending FATTR4_ARCHIVE in createattrs as part of
OPEN and fails to create any file.

decode method for FATTR4_ARCHIVE is not implemented, it returns NOOP. I
figured that the read-only attributes do not need a decode method, but
FATTR4_ARCHIVE is a read-write attribute according to RFCs (3530 and 5661).
Is there any specific reason decode is not implemented for archive?

Also, I am not sure if there is any official windows client for NFSv4, I
was using the one published by cohortfs. Is there some other windows client
with which NFS Ganesha works seamlessly?

Thanks,
Sriram
--
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] Request: I'm looking for good file system test programs

[sriram patil]

Hi Kevin,

You can take a look at xfstests. It does data correctness checks as well.
You will have to google for figuring out the download and build procedure.

- Sriram

On Tue, Jan 17, 2017 at 1:07 AM, Kevin C.  wrote:

>
> I'm looking for file system operation/stability test programs.
>
>
> I'm most interested in test programs that do many file operations that
> are then verified rather than programs that concentrate on performance
> tests.
>
>
> Thanks in advance,
>
> Kevin
>
>
>
>
> 
> --
> 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] Kerberos: Not working because response uses cached krb service from authgss_hash

[sriram patil]

Hi Matt,

Following is the link for pull request.

Pull request.
<https://github.com/nfs-ganesha/ntirpc/pull/31/commits/334e4c1c03109f0b5b43e154f5b389329831a2d8>

Will add a separate pull request for ganesha changes as well.

Thanks,
Sriram


On Mon, Dec 19, 2016 at 8:46 PM, Matt Benjamin <mbenja...@redhat.com> wrote:

> Hi Sriram,
>
> Please send your change as a pull request against https://github.com/nfs-
> ganesha/ntirpc.  We need to take some care to ensure that we properly
> enforce service and QOP guarantees.  My understanding would have been that
> any request "still being processed" has been validated and unwrapped.  If
> that's the case, then I do suspect that any further use of the request
> version of the service value is valid.
>
> Matt
>
> - Original Message -
> > From: "sriram patil" <spsrirampa...@gmail.com>
> > To: nfs-ganesha-devel@lists.sourceforge.net
> > Sent: Monday, December 19, 2016 2:23:36 AM
> > Subject: [Nfs-ganesha-devel] Kerberos: Not working because response
> uses  cached krb service from authgss_hash
> >
> >
> >
> > Hi,
> >
> > When handling kerberos requests ganesha fetches the cached
> svc_rpc_gss_data
> > from authgss_hash. If the kerberos service (authentication, integrity or
> > privacy) do not match with the one parsed from the request, ganesha
> changes
> > the service value in the cache. And continues to use the cached object
> for
> > all the further verification and when sending response to the client.
> Note
> > that there is no local copy of the gss data in the request, it uses the
> > cached object.
> >
> >
> >
> >
> > Code snippet which does the above mentioned lookup:
> >
> >
> > file: src/libntirpc/src/svc_auth_gss.c function: _svcauth_gss
> >
> > ` /* Context lookup. */
> >
> > if ((gc->gc_proc == RPCSEC_GSS_DATA)
> >
> > || (gc->gc_proc == RPCSEC_GSS_DESTROY)) {
> >
> > /* XXX fix prototype, toss junk args */
> >
> > gd = authgss_ctx_hash_get(gc);
> >
> > if (!gd)
> >
> > svcauth_gss_return(AUTH_REJECTEDCRED);
> >
> > gd_hashed = true;
> >
> > if (gc->gc_svc != gd->sec.svc)
> >
> > gd->sec.svc = gc->gc_svc;
> >
> > }`
> >
> >
> >
> >
> > Now let’s assume that the cached gss service is set to privacy (3).
> Before
> > the ongoing request can proceed, a new request comes in with OP_RENEW and
> > gss service set to integrity (2). As specified in the above snippet, this
> > will change the gss service value in the cache to integrity. This will
> > affect all the requests which are still being processed and may respond
> to
> > client with an incorrect gss service. Because of this the nfs client is
> > unable to interpret the response and fails with EIO. I am using linux nfs
> > client so it fails in method gss_unwrap_resp.
> >
> > I am continuously hitting this issue in case of server restarts when
> mounted
> > on the client with kerberos privacy. Is there any reason why we use the
> gss
> > service from the cache, though we have a local copy parsed from the
> actual
> > request stored in (rq_clntcred).
> >
> >
> > I have tried a fix to always use the gss service from the request
> > (rq_clntcred). This is working as expected and no errors on the client
> side.
> >
> >
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Sriram
> >
> > 
> --
> > 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
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Kerberos with virtual IP failovers

[sriram patil]

Hi All

I have been trying to setup HA feature with VIP failovers for nfs ganesha.
I have been able to successfully setup HA for sys authentication flavour. I
am facing problem with GSS authentication for HA feature.

I have exported my mount point krb5 and have mounted on a different
machine. All the operations succeed. Now I move the vip to a different
machine with same export configuration. All current running operations fail
(like dd) but then subsequent operations succeed. CURRENT RUNNING
operations fail with Remote I/O Error.

Apparently, it is failing the export_check_security method, where it is
always receiving RPCSEC_GSS_SVC_INTEGRITY in the request. Printing the
following error in the log

"Export /mnt does not support RPCSEC_GSS_SVC_INTEGRITY"

I could observe in the logs that SETCLIENTID and SETCLIENTID_CONFIRM went
through without any problem. But, the subsequent RENEW op fails with the
above mentioned error.

NFS client debug logs show the following error

nfs4_recovery_handle_error: failed to handle error -5 for server
10.10.102.220
kernel: NFS: state manager: check lease failed on NFSv4 server
10.10.102.220 with error 5

Note that, if I export and mount with krb5i then everything works fine.
Even the current running operations complete successfully.

Is it a bug or am I missing something?

Thanks,
Sriram
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID

[sriram patil]

Great! Will get upto speed with it then .

Thanks.

On Mon, Aug 15, 2016, 9:53 PM Frank Filz <ffilz...@mindspring.com> wrote:

> It’s not in plan by anyone actively working on Ganesha, but we always
> welcome new participants in the community.
>
>
>
> Frank
>
>
>
> *From:* Sriram Patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Monday, August 15, 2016 9:05 AM
> *To:* Frank Filz <ffilz...@mindspring.com>
> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* RE: [Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID
>
>
>
> Yes, sure. Do you know if it is a planned change for ganesha?
>
> Thanks,
> Sriram
>
> On Mon, Aug 15, 2016 at 9:29 PM, Frank Filz <ffilz...@mindspring.com>
> wrote:
>
>
>
> Well, we could make the code changes necessary to allow an FSAL’s
> supported attributes to actually be represented as the supported attributes
> for that export.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com
> <spsrirampa...@gmail.com>]
> *Sent:* Sunday, August 14, 2016 11:51 PM
> *To:* Frank Filz <ffilz...@mindspring.com>;
> nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID
>
>
>
> Thank you for the response Frank. I do not want to set the same fileid for
> all files, I was just trying to disable ATTR_FILEID.
>
>
>
> But, as you have mentioned it is not possible without any code changes in
> the ganesha source code.
>
>
>
> Thanks,
>
> Sriram
>
>
>
> On Fri, Aug 12, 2016 at 9:47 PM Frank Filz <ffilz...@mindspring.com>
> wrote:
>
> What is your intent with disabling fileid and setting it the same for all
> inodes?
>
>
>
> That will likely confuse clients (at least in some instances, for example,
> find will complain).
>
>
>
> I’m not sure what the client would do if you truly removed it.
>
>
>
> The way encode_supported_attrs() is coded in nfs_proto_tools.c, the
> attributes Ganesha claims support from are static and independent of what
> the FSAL supports. If we have a genuine need to have different support
> depending on FSAL, we will need to recode this function.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Friday, August 12, 2016 12:09 AM
> *To:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* [Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID
>
>
>
> Hi,
>
>
>
> I wanted to disable ATTR_FILEID for my implementation. I removed it from
> the mask returned in fs_supported_attrs. Also, I am explicitly unsetting it
> in getattrs, lookup and lookup_path. But as I see on the client side, it is
> still honouring the value set in fileid.
>
>
>
> I am setting st_ino = 2 for all the files and directories, converting to
> fsal attributes and then unsetting ATTR_FILEID in attr->mask. When I mount
> on other machine I can still see the inode numbers for all files as 2.
>
>
>
> Am I missing something here? Is there some other way to disable
> ATTR_FILEID?
>
>
>
> Thanks,
>
> Sriram
>
>
> --
>
> [image: Avast logo]
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
>
>
>
> --
>
> [image: Avast logo]
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
>
>
>
>
> --
> [image: Avast logo]
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID

[sriram patil]

Thank you Daniel. Will figure out some other approach then.

Thanks,
Sriram

On Fri, Aug 12, 2016 at 6:46 PM Daniel Gryniewicz <d...@redhat.com> wrote:

> FileID and FSID are handled specially.  They're always valid, and stored
> in the fsal_obj_handle itself, not in the attributes.  As currently
> coded, I don't think you can disable either of them.
>
> Daniel
>
> On 08/12/2016 03:09 AM, sriram patil wrote:
> > Hi,
> >
> > I wanted to disable ATTR_FILEID for my implementation. I removed it from
> > the mask returned in fs_supported_attrs. Also, I am explicitly unsetting
> > it in getattrs, lookup and lookup_path. But as I see on the client side,
> > it is still honouring the value set in fileid.
> >
> > I am setting st_ino = 2 for all the files and directories, converting to
> > fsal attributes and then unsetting ATTR_FILEID in attr->mask. When I
> > mount on other machine I can still see the inode numbers for all files
> as 2.
> >
> > Am I missing something here? Is there some other way to disable
> ATTR_FILEID?
> >
> > Thanks,
> > Sriram
> >
> >
> >
> --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. http://sdm.link/zohodev2dev
> >
> >
> >
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID

[sriram patil]

Thank you for the response Frank. I do not want to set the same fileid for
all files, I was just trying to disable ATTR_FILEID.

But, as you have mentioned it is not possible without any code changes in
the ganesha source code.

Thanks,
Sriram

On Fri, Aug 12, 2016 at 9:47 PM Frank Filz <ffilz...@mindspring.com> wrote:

> What is your intent with disabling fileid and setting it the same for all
> inodes?
>
>
>
> That will likely confuse clients (at least in some instances, for example,
> find will complain).
>
>
>
> I’m not sure what the client would do if you truly removed it.
>
>
>
> The way encode_supported_attrs() is coded in nfs_proto_tools.c, the
> attributes Ganesha claims support from are static and independent of what
> the FSAL supports. If we have a genuine need to have different support
> depending on FSAL, we will need to recode this function.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Friday, August 12, 2016 12:09 AM
> *To:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* [Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID
>
>
>
> Hi,
>
>
>
> I wanted to disable ATTR_FILEID for my implementation. I removed it from
> the mask returned in fs_supported_attrs. Also, I am explicitly unsetting it
> in getattrs, lookup and lookup_path. But as I see on the client side, it is
> still honouring the value set in fileid.
>
>
>
> I am setting st_ino = 2 for all the files and directories, converting to
> fsal attributes and then unsetting ATTR_FILEID in attr->mask. When I mount
> on other machine I can still see the inode numbers for all files as 2.
>
>
>
> Am I missing something here? Is there some other way to disable
> ATTR_FILEID?
>
>
>
> Thanks,
>
> Sriram
>
>
> --
> [image: Avast logo]
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Fwd: How to disable ATTR_FILEID

[sriram patil]

Hi,

I wanted to disable ATTR_FILEID for my implementation. I removed it from
the mask returned in fs_supported_attrs. Also, I am explicitly unsetting it
in getattrs, lookup and lookup_path. But as I see on the client side, it is
still honouring the value set in fileid.

I am setting st_ino = 2 for all the files and directories, converting to
fsal attributes and then unsetting ATTR_FILEID in attr->mask. When I mount
on other machine I can still see the inode numbers for all files as 2.

Am I missing something here? Is there some other way to disable ATTR_FILEID?

Thanks,
Sriram
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel