date:20180208

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

2018-02-08 Thread 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 
Date: Friday, February 9, 2018 at 12:05 AM
To: Sriram Patil , 
"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 ; 
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 >
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil >, 
"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 >; 
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add debug surrounding FSAL module refcounting

2018-02-08 Thread GerritHub

>From Frank Filz :

Frank Filz has uploaded this change for review. ( 
https://review.gerrithub.io/399077


Change subject: Add debug surrounding FSAL module refcounting
..

Add debug surrounding FSAL module refcounting

Change-Id: Ie31bc45777e19c721c45d90abefd0ef5aac92022
Signed-off-by: Frank S. Filz 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_export.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_main.c
M src/FSAL/Stackable_FSALs/FSAL_NULL/export.c
M src/FSAL/fsal_destroyer.c
M src/FSAL/fsal_manager.c
M src/support/ds.c
M src/support/exports.c
7 files changed, 80 insertions(+), 0 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/77/399077/1
--
To view, visit https://review.gerrithub.io/399077
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie31bc45777e19c721c45d90abefd0ef5aac92022
Gerrit-Change-Number: 399077
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Don't double stack MDCACHE on FSAL_PSEUDO exports

2018-02-08 Thread GerritHub

>From Frank Filz :

Frank Filz has uploaded this change for review. ( 
https://review.gerrithub.io/399078


Change subject: Don't double stack MDCACHE on FSAL_PSEUDO exports
..

Don't double stack MDCACHE on FSAL_PSEUDO exports

Change-Id: I8c827f97b2c0b664b5ec59024a5598fc0ecb7dc5
Signed-off-by: Frank S. Filz 
---
M src/support/exports.c
1 file changed, 15 insertions(+), 5 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/78/399078/1
--
To view, visit https://review.gerrithub.io/399078
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I8c827f97b2c0b664b5ec59024a5598fc0ecb7dc5
Gerrit-Change-Number: 399078
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Using root privileges when using kerberos exports with Ganesha.

2018-02-08 Thread Pradeep

Hello,

It looks like Ganesha converts certain principals to UID/GID 0
(idmapper.c:principal2uid()). I noticed that when a client uses kerberos
with AD, the default principal is @. So when NFS operations
are tried with root on client, it sends the principal in @
format which will not be mapped to UID/GID 0 on Ganesha side.

Have anyone successfully used privileged access to NFS exports with
Kerberos/AD with Ganesha server? If yes, could share how you were able to
achieve that?

Thanks,
Pradeep
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: MDCACHE - Don't ref PSEUDO when stacking

2018-02-08 Thread GerritHub

>From Daniel Gryniewicz :

Daniel Gryniewicz has uploaded this change for review. ( 
https://review.gerrithub.io/398977


Change subject: MDCACHE - Don't ref PSEUDO when stacking
..

MDCACHE - Don't ref PSEUDO when stacking

Currently, for FSAL stacks, MDCACHE is taking over the global ref when
it's autostacked.  However, for the pseudoroot, it was taking an extra
ref, causing a ref leak.  Remove this extra ref.

Change-Id: Ib254825f7277a0c14c0c0a40a498a75a7696f7c5
Signed-off-by: Daniel Gryniewicz 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_export.c
1 file changed, 1 insertion(+), 2 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/77/398977/1
--
To view, visit https://review.gerrithub.io/398977
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib254825f7277a0c14c0c0a40a498a75a7696f7c5
Gerrit-Change-Number: 398977
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Pullup ntirpc 1.6.1

2018-02-08 Thread GerritHub

>From Daniel Gryniewicz :

Daniel Gryniewicz has uploaded this change for review. ( 
https://review.gerrithub.io/398978


Change subject: Pullup ntirpc 1.6.1
..

Pullup ntirpc 1.6.1

Change-Id: I4ab3ce3ce093ec4d25c1a8ff362b500fb8c2
Signed-off-by: Daniel Gryniewicz 
---
M src/CMakeLists.txt
M src/libntirpc
2 files changed, 2 insertions(+), 2 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/78/398978/1
--
To view, visit https://review.gerrithub.io/398978
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I4ab3ce3ce093ec4d25c1a8ff362b500fb8c2
Gerrit-Change-Number: 398978
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz 
--
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

2018-02-08 Thread Frank Filz

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 ; 
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  >
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil  >, 
"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  >; 
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

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

2018-02-08 Thread 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 
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil , 
"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 ; 
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 >
Date: Thursday, February 8, 2018 at 12:24 AM
To: Sriram Patil >, 
"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

[age

Re: [Nfs-ganesha-devel] owner and group issue.

2018-02-08 Thread Daniel Gryniewicz


This is not a known issue, as far as I'm aware.

I'm assuming you never changed 4.txt at all, it just fixed itself on 
it's own?  This means, to me, that the correct value is being set on the 
file, but an incorrect one is returned to the user.  That's a getattr() 
issue, and it resolves itself because after 60 seconds, the attribute 
cache expires, and so the next getattr refreshes the cache, fixing the 
issue.


Is your FSAL correctly returning the attributes in attrs_out in it's 
open2() call?


Daniel

On 02/08/2018 05:15 AM, Sagar M D wrote:

Hi,

We are using nfs-ganesha 2.5 for our fsal, I see sometimes created file 
have -2 has owner and group even though root is created the file and 
no_root_squash is enabled.


I see this behavior for only for short duration that to right after 
ganesha restarts.


During file creation, our fsal gets correct owner and group. But ls -ltr 
is showing -2. If i try after few mins all works fine.


[root@BDC testPerm]# touch 4.txt
[root@BDC testPerm]# ls -ltr
total 0
-rw-r--r--. 1 root   root   0 Feb  7 20:10 1.txt
-rw-r--r--. 1 root   root   0 Feb  7 20:17 2.txt
-rw-r--r--. 1 root   root   0 Feb  7 20:17 3.txt
-rw-r--r--. 1 4294967294 4294967294 0 Feb  7 20:21 4.txt


ls tried after some time:-
[root@BDC testPerm]# touch 5.txt
[root@BDC testPerm]# ls -ltr
total 0
-rw-r--r--. 1 root root 0 Feb  7 20:10 1.txt
-rw-r--r--. 1 root root 0 Feb  7 20:17 2.txt
-rw-r--r--. 1 root root 0 Feb  7 20:17 3.txt
-rw-r--r--. 1 root root 0 Feb  7 20:21 4.txt
-rw-r--r--. 1 root root 0 Feb  7 20:33 5.txt

is there any known issues ? Are we missing anything from our side?

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




--
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] New things in feature board

2018-02-08 Thread Frank Filz

We will actually need to add everyone who is interested to the organization 
anyway, otherwise we can’t assign them issues…



Problems with how issues were assigned was actually one of the reasons we tried 
to migrate to Bugzilla and not use issues. But with this, we just need to bite 
the bullet and get everyone who needs to be properly into the organization.



Frank



From: Supriti Singh [mailto:supriti.si...@suse.com]
Sent: Thursday, February 8, 2018 3:42 AM
To: nfs-ganesha-devel@lists.sourceforge.net; srir...@vmware.com
Subject: Re: [Nfs-ganesha-devel] New things in feature board



Hi Sriram,

Earlier we had boards at the repo level 
(https://github.com/nfs-ganesha/nfs-ganesha/projects), but there were some 
permission issues, and it could be viewed by everyone but not all can add 
cards.  So we moved the board to organization level. But sadly, according to 
this (https://github.com/isaacs/github/issues/935) only those who are members 
of organization can view the board.



Possible solution would be to figure out if we can move this board again to 
repo level, and figure out permissions. Meanwhile, Frank has rights to add 
people in organization. Github permissions are bit inconvenient.



--

Supriti Singh

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,

HRB 21284 (AG Nürnberg)


>>> Sriram Patil  > 02/08/18 
>>> 12:30 PM >>>

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)





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

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

2018-02-08 Thread Frank Filz

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 ; 
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  >
Date: Thursday, February 8, 2018 at 12:24 AM
To: Sriram Patil  >, 
"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




 


Virus-free.

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

2018-02-08 Thread 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] New things in feature board

2018-02-08 Thread Supriti Singh

Hi Sriram,

Earlier we had boards at the repo level 
(https://github.com/nfs-ganesha/nfs-ganesha/projects), but there were some
permission issues, and it could be viewed by everyone but not all can add 
cards.  So we moved the board to organization
level. But sadly, according to this 
(https://github.com/isaacs/github/issues/935) only those who are members of
organization can view the board. 

Possible solution would be to figure out if we can move this board again to 
repo level, and figure out permissions.
Meanwhile, Frank has rights to add people in organization. Github permissions 
are bit inconvenient. 


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



>>> Sriram Patil  02/08/18 12:30 PM >>>
  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

[Nfs-ganesha-devel] owner and group issue.

2018-02-08 Thread Sagar M D

Hi,

We are using nfs-ganesha 2.5 for our fsal, I see sometimes created file
have -2 has owner and group even though root is created the file and
no_root_squash is enabled.

I see this behavior for only for short duration that to right after ganesha
restarts.

During file creation, our fsal gets correct owner and group. But ls -ltr is
showing -2. If i try after few mins all works fine.

[root@BDC testPerm]# touch 4.txt
[root@BDC testPerm]# ls -ltr
total 0
-rw-r--r--. 1 root   root   0 Feb  7 20:10 1.txt
-rw-r--r--. 1 root   root   0 Feb  7 20:17 2.txt
-rw-r--r--. 1 root   root   0 Feb  7 20:17 3.txt
-rw-r--r--. 1 4294967294 4294967294 0 Feb  7 20:21 4.txt


ls tried after some time:-
[root@BDC testPerm]# touch 5.txt
[root@BDC testPerm]# ls -ltr
total 0
-rw-r--r--. 1 root root 0 Feb  7 20:10 1.txt
-rw-r--r--. 1 root root 0 Feb  7 20:17 2.txt
-rw-r--r--. 1 root root 0 Feb  7 20:17 3.txt
-rw-r--r--. 1 root root 0 Feb  7 20:21 4.txt
-rw-r--r--. 1 root root 0 Feb  7 20:33 5.txt

is there any known issues ? Are we missing anything from our side?

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] New things in feature board

2018-02-08 Thread Supriti Singh

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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add debug surrounding FSAL module refcounting

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Don't double stack MDCACHE on FSAL_PSEUDO exports

[Nfs-ganesha-devel] Using root privileges when using kerberos exports with Ganesha.

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: MDCACHE - Don't ref PSEUDO when stacking

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Pullup ntirpc 1.6.1

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

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

Re: [Nfs-ganesha-devel] owner and group issue.

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

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

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

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

[Nfs-ganesha-devel] owner and group issue.

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

15 matches

Site Navigation

Mail list logo

Footer information