[Nfs-ganesha-devel] Announce Push of V2.6.0

2018-02-19 Thread Frank Filz 
Branch next

 

Tag:V2.6.0

 

Release Highlights

 

* A variety of cleanup things

 

* Bump FSAL version

 

* For gluster, pnfs_mds is false by default.

 

* Fix copyrights on FSAL_MEM

 

* move read EOF handling to fsal_read2

 

* NFS: fix delegation conflict check in open4_ex

 

* dbus: don't call dbus_bus_release_name if dbus setup failed

 

* Don't leak netconfig entities

 

Signed-off-by: Frank S. Filz 

 

Contents:

 

9786797 Frank S. Filz V2.6.0

3b65088 Frank S. Filz Bump FSAL_API major version to 7.0

c5feb7d Jeff Layton NFS: fix delegation conflict check in open4_ex

89348b0 Jeff Layton dbus: don't call dbus_bus_release_name if dbus setup
failed

8858a4a Paul Emmerich move read EOF handling to fsal_read2

dc1c6ab Girjesh Rajoria gtest/test_rename_latency: rename latency
microbenchmark

6f88934 Girjesh Rajoria gtest/test_unlink_latency: unlink latency
microbenchmark

412cc68 Supriti Singh For gluster, pnfs_mds is false by default. User should
set it to true for both NFSv4 and pnfs_mds block

0155434 Daniel Gryniewicz Fix copyrights on FSAL_MEM

eea4702 Daniel Gryniewicz Don't leak netconfig entities

--
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]: dbus: don't call dbus_bus_release_name if dbus setup failed

2018-02-19 Thread GerritHub 
>From Jeff Layton :

Jeff Layton has uploaded this change for review. ( 
https://review.gerrithub.io/400292


Change subject: dbus: don't call dbus_bus_release_name if dbus setup failed
..

dbus: don't call dbus_bus_release_name if dbus setup failed

We can end up with a NULL dbus_conn if dbus initialization fails. Only
do the teardown if it succeeded.

Change-Id: Ib6e6c2c1209eb8f94d2461e2292b1af835f5a2b9
Signed-off-by: Jeff Layton 
---
M src/dbus/dbus_server.c
1 file changed, 17 insertions(+), 15 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib6e6c2c1209eb8f94d2461e2292b1af835f5a2b9
Gerrit-Change-Number: 400292
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton 
--
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] nfs ganesha vs nfs kernel performance

2018-02-19 Thread Matt Benjamin 
On Fri, Feb 16, 2018 at 11:23 AM, William Allen Simpson
 wrote:

>>
> Actually, 2.6 should handle as many concurrent client requests as you like.
> (Up to 250 of them.)  That's one of its features.
>
> The client is not sending concurrent requests.

This seems worth digging into.  That's my understanding of 2.6
dispatch too, anyway.

>
>>
> But the planned 2.7 improvements are mostly throughput related, not IOPS.

Not at all, though I am trying to ensure that we get async FSAL ops
in.  There are people working on IOPs too.

>
>
> If Ganesha is adding 6 ms to every read operation, we have a serious
> problem, and need to profile immediately!
>

That's kind of what our team is doing.  I look forward to your work
with rpc-ping-mt.

Matt


-- 

Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-821-5101
fax.  734-769-8938
cel.  734-216-5309

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

Re: [Nfs-ganesha-devel] READDIR doesn't return all entries.

2018-02-19 Thread William Allen Simpson 

On 2/13/18 8:00 PM, Frank Filz wrote:

You still don’t mention FSAL…

I’m suspecting non-unique cookies from the FSAL as a cause. You may want to turn on CACHE_INODE and NFS_READDIR to FULL_DEBUG to see what is going on. A tcpdump trace won’t show anything useful (since we won’t see what cookies are being provided for the 
missing directory entries).



It's been several days, and nobody has been able to reproduce.

Please send your entire configuration.

--
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] ACL support

2018-02-19 Thread Sagar M D 
Sriram,

I was using nfsv4 acl commands only.

[root@BDC sagar]# nfs4_getfacl 1.txt
Operation to request attribute not supported.

[root@BDC sagar]# nfs4_setfacl  -a A::10:rxtncy 1.txt
Operation to request attribute not supported.
Failed to instantiate ACL.

Thanks,
Sagar.


On Fri, Feb 16, 2018 at 4:20 PM, Sriram Patil  wrote:

> 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"  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] Change in ffilz/nfs-ganesha[next]: Create the LUSTRE FSAL over VFS FSAL

2018-02-19 Thread GerritHub 
>From Patrice LUCAS :

Patrice LUCAS has uploaded this change for review. ( 
https://review.gerrithub.io/400517


Change subject: Create the LUSTRE FSAL over VFS FSAL
..

Create the LUSTRE FSAL over VFS FSAL

This initial Lustre FSAL code is as nearest as possible from the
VFS FSAL code.

It only adds an HSM check to trigger an hsm restore and return
ERR_FSAL_DELAY when a file is released. An option of export is
added to set/unset this behaviour : async_hsm_restore. For
example, 9P clients don't support retry.

If we don't have an up to date lustre api, we still compile a
"fake" LUSTRE FSAL to continue to check the compilation path.

Change-Id: Ibe495fd0467ab6b86c1eb369099a78fc048d55a0
Signed-off-by: Patrice LUCAS 
---
M src/CMakeLists.txt
M src/FSAL/CMakeLists.txt
M src/FSAL/FSAL_VFS/CMakeLists.txt
A src/FSAL/FSAL_VFS/empty_check_hsm.c
M src/FSAL/FSAL_VFS/file.c
M src/FSAL/FSAL_VFS/panfs/CMakeLists.txt
M src/FSAL/FSAL_VFS/vfs/CMakeLists.txt
A src/FSAL/FSAL_VFS/vfs/llapi_check_hsm.c
R src/FSAL/FSAL_VFS/vfs/main-c.in.cmake
M src/FSAL/FSAL_VFS/vfs/subfsal_vfs.c
M src/FSAL/FSAL_VFS/vfs_methods.h
M src/FSAL/FSAL_VFS/xfs/CMakeLists.txt
M src/config_samples/config.txt
M src/include/config-h.in.cmake
M src/include/fsal_handle_syscalls.h
M src/nfs-ganesha.spec-in.cmake
16 files changed, 281 insertions(+), 23 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/17/400517/1
--
To view, visit https://review.gerrithub.io/400517
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ibe495fd0467ab6b86c1eb369099a78fc048d55a0
Gerrit-Change-Number: 400517
Gerrit-PatchSet: 1
Gerrit-Owner: Patrice LUCAS 
--
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] ACL support

2018-02-19 Thread 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 
Date: Friday, February 16, 2018 at 8:19 PM
To: Sriram Patil , 'Sagar M D' , 
'Supriti Singh' 
Cc: "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 ; Supriti Singh 
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 >
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!

Re: [Nfs-ganesha-devel] ACL support

2018-02-19 Thread Sagar M D 
Sriram,

Setting ATTR_ACL in supported_attrs helped. Now I could able to get the V4
ACLs. Thanks!.

Frank,
Currently we are doing what you are suggesting i.e we are persistently
saving the in-memory representation of ganesha NFSV4 ACL on disk.
And I'm not sure whether we are ready to check in our fsal into ganesha
yet. We will discuss this internally.

Thanks!

On Fri, Feb 16, 2018 at 9:21 PM, Sriram Patil  wrote:

> 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 
> *Date: *Friday, February 16, 2018 at 8:19 PM
> *To: *Sriram Patil , 'Sagar M D' ,
> 'Supriti Singh' 
> *Cc: *"nfs-ganesha-devel@lists.sourceforge.net"  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 ; 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 
> *Date: *Friday, February 16, 2018 at 3:20 PM
> *To: *Supriti Singh 
> *Cc: *"nfs-ganesha-devel@lists.sourceforge.net"  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