[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add auto expiration of idmap cache entry

2018-03-08 Thread GerritHub 
>From Malahal :

Malahal has uploaded this change for review. ( 
https://review.gerrithub.io/403267


Change subject: Add auto expiration of idmap cache entry
..

Add auto expiration of idmap cache entry

idmapper cache entries (username<->uid or groupname<->gid) don't
expire.  There is a way to expire all of the entries by using a dbus
method but there is no auto expiration of an entry after a certain
time period.  This patch adds auto expiration after
manage_gids_expiration time period.

Change-Id: Ibefcbd707681127a1e5e9dd8847d6d8d3b6f8fd4
Signed-off-by: Malahal Naineni 
---
M src/idmapper/idmapper_cache.c
1 file changed, 15 insertions(+), 6 deletions(-)



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

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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add purging gids cache to ganesha_mgr script

2018-03-08 Thread GerritHub 
>From Malahal :

Malahal has uploaded this change for review. ( 
https://review.gerrithub.io/403269


Change subject: Add purging gids cache to ganesha_mgr script
..

Add purging gids cache to ganesha_mgr script

Currently there is a standalone purge_gids python script to purge gids
cache. Add this functionality into ganesha_mgr script and remove the
standalone script.

Change-Id: If9d523724d10e2af172c920b18b2c82966185ff8
Signed-off-by: Malahal Naineni 
---
M src/nfs-ganesha.spec-in.cmake
M src/scripts/ganeshactl/CMakeLists.txt
M src/scripts/ganeshactl/Ganesha/ganesha_mgr_utils.py
M src/scripts/ganeshactl/ganesha_mgr.py
D src/scripts/ganeshactl/purge_gids.py
5 files changed, 21 insertions(+), 25 deletions(-)



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

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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add purging idmapper cache to ganesha_mgr script

2018-03-08 Thread GerritHub 
>From Malahal :

Malahal has uploaded this change for review. ( 
https://review.gerrithub.io/403268


Change subject: Add purging idmapper cache to ganesha_mgr script
..

Add purging idmapper cache to ganesha_mgr script

ganesha_mgr dbus script manages purging netgroups cache. Add purging
idmapper cache to it as well. Usage: ganesha_mgr purge idmap

Change-Id: Ic02c1d0b0648ff4fd40432633f17d68e190aa342
Signed-off-by: Malahal Naineni 
---
M src/scripts/ganeshactl/Ganesha/ganesha_mgr_utils.py
M src/scripts/ganeshactl/ganesha_mgr.py
2 files changed, 23 insertions(+), 2 deletions(-)



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

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

Re: [Nfs-ganesha-devel] rpcping

2018-03-08 Thread William Allen Simpson 

On 3/8/18 12:33 PM, William Allen Simpson wrote:

Still having no luck.  Instead of relying on RPC itself, checked
with Ganesha about what it registers, and tried some of those.


Without running Ganesha, rpcinfo reports portmapper services by default
on my machine.  Can talk to it via localhost (but not 127.0.0.1 loopback).

bill@simpson91:~/rdma/build_ganesha$ rpcinfo
   program version netid addressserviceowner
104tcp6  ::.0.111   portmapper superuser
103tcp6  ::.0.111   portmapper superuser
104udp6  ::.0.111   portmapper superuser
103udp6  ::.0.111   portmapper superuser
104tcp   0.0.0.0.0.111  portmapper superuser
103tcp   0.0.0.0.0.111  portmapper superuser
102tcp   0.0.0.0.0.111  portmapper superuser
104udp   0.0.0.0.0.111  portmapper superuser
103udp   0.0.0.0.0.111  portmapper superuser
102udp   0.0.0.0.0.111  portmapper superuser
104local /run/rpcbind.sock  portmapper superuser
103local /run/rpcbind.sock  portmapper superuser

TCP works.  UDP with the same parameters hangs forever.

tests/rpcping tcp localhost 1 1000 10 4
rpcping tcp localhost threads=1 count=1000 (program=10 version=4 
procedure=0): 5., total 5.
tests/rpcping tcp localhost 1 1 10 4
rpcping tcp localhost threads=1 count=1 (program=10 version=4 
procedure=0): 17543.8596, total 17543.8596
tests/rpcping tcp localhost 1 10 10 4
^C

What's interesting to me is that 1,000 async calls has much
better throughput (calls per second) than 10,000.  Hard to
say where is the bottleneck without profiling.

100,000 async calls bogs down so long that I gave up.  Same
with 2 threads and 10,000 -- or 3 threads down to 100.

tests/rpcping tcp localhost 2 1000 10 4
rpcping tcp localhost threads=2 count=1000 (program=10 version=4 
procedure=0): 8333., total 1.6667
tests/rpcping tcp localhost 2 1 10 4
^C

tests/rpcping tcp localhost 3 1000 10 4
^C
tests/rpcping tcp localhost 3 500 10 4
^C
tests/rpcping tcp localhost 3 100 10 4
rpcping tcp localhost threads=3 count=100 (program=10 version=4 
procedure=0): .6667, total 2.
tests/rpcping tcp localhost 5 100 10 4
rpcping tcp localhost threads=5 count=100 (program=10 version=4 
procedure=0): 1., total 5.
tests/rpcping tcp localhost 7 100 10 4
rpcping tcp localhost threads=7 count=100 (program=10 version=4 
procedure=0): 8571.4286, total 6.
tests/rpcping tcp localhost 10 100 10 4
rpcping tcp localhost threads=10 count=100 (program=10 version=4 
procedure=0): 7000., total 7.
tests/rpcping tcp localhost 15 100 10 4
rpcping tcp localhost threads=15 count=100 (program=10 version=4 
procedure=0): 5666.6667, total 85000.
tests/rpcping tcp localhost 20 100 10 4
rpcping tcp localhost threads=20 count=100 (program=10 version=4 
procedure=0): 3750., total 75000.
tests/rpcping tcp localhost 25 100 10 4
rpcping tcp localhost threads=25 count=100 (program=10 version=4 
procedure=0): 2420., total 60500.

Note that 5 threads and 100 catches up to 1 thread and 1,000?

So the bottleneck is probably in ntirpc.  That seems validated by 7 to
25 threads; portmapper will handle more requests (with diminishing
returns), but ntirpc cannot handle more results (on the same thread).

Oh well, against nfs-ganesha still doesn't work.

tests/rpcping tcp localhost 1 10 13 4
clnt_ncreate failed: RPC: Unknown protocol
tests/rpcping tcp localhost 1 10 13 3
clnt_ncreate failed: RPC: Unknown protocol

But it's in the rpcinfo:

   program version netid addressserviceowner
104tcp6  ::.0.111   portmapper superuser
103tcp6  ::.0.111   portmapper superuser
104udp6  ::.0.111   portmapper superuser
103udp6  ::.0.111   portmapper superuser
104tcp   0.0.0.0.0.111  portmapper superuser
103tcp   0.0.0.0.0.111  portmapper superuser
102tcp   0.0.0.0.0.111  portmapper superuser
104udp   0.0.0.0.0.111  portmapper superuser
103udp   0.0.0.0.0.111  portmapper superuser
102udp   0.0.0.0.0.111  portmapper superuser
104local /run/rpcbind.sock  portmapper superuser
103local /run/rpcbind.sock  portmapper superuser
133udp   0.0.0.0.8.1nfssuperuser
133udp6  :::0.0.0.0.8.1

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Pullup NTIRPC through #112

2018-03-08 Thread GerritHub 
>From :

william.allen.simp...@gmail.com has uploaded this change for review. ( 
https://review.gerrithub.io/403209


Change subject: Pullup NTIRPC through #112
..

Pullup NTIRPC through #112

Change-Id: I87171d4c07293c99bb312e09e1007f7f43141c1a
Signed-off-by: William Allen Simpson 
---
M src/Protocols/XDR/xdr_mount.c
M src/Protocols/XDR/xdr_nfs23.c
M src/include/nfsv41.h
M src/libntirpc
4 files changed, 17 insertions(+), 24 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I87171d4c07293c99bb312e09e1007f7f43141c1a
Gerrit-Change-Number: 403209
Gerrit-PatchSet: 1
Gerrit-Owner: william.allen.simp...@gmail.com
--
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] rpcping

2018-03-08 Thread William Allen Simpson 

Still having no luck.  Instead of relying on RPC itself, checked
with Ganesha about what it registers, and tried some of those.

The default procedure is 0, that according to every RFC is reserved for
do nothing.  But rpcbind is not finding program and version.

To be honest, I'm not sure how this can ever be used for real testing.
According to the documentation:

3.3.0 Procedure 0: NULL - Do nothing
...
  Since the NULL procedure takes no NFS version 3 protocol
  arguments and returns no NFS version 3 protocol response,
  it can not return an NFS version 3 protocol error.

But we need some kind of response for timing!

bill@simpson91:~/rdma/ntirpc$ cd ../build~ntirpc/
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping
Usage: rpcping[ [ [ 
[

NFS

bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp localhost 1 10 13 2
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp localhost 1 10 13 3
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp localhost 1 10 13 4
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 13 4
clnt_ncreate failed: RPC: Unknown protocol


Mount

bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 15 4
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 15 3
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 15 2
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 15 1
clnt_ncreate failed: RPC: Unknown protocol


rpcbind itself

bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 10 1
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 10 2
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 10 3
clnt_ncreate failed: RPC: Unknown protocol
bill@simpson91:~/rdma/build~ntirpc$ tests/rpcping tcp 127.0.0.1 1 10 10 4
clnt_ncreate failed: RPC: Unknown protocol

--
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]: Fixed: https://github.com/nfs-ganesha/nfs-ganesha/issues/275

2018-03-08 Thread GerritHub 
>From CHEN TAO :

CHEN TAO has uploaded this change for review. ( 
https://review.gerrithub.io/403203


Change subject: Fixed: https://github.com/nfs-ganesha/nfs-ganesha/issues/275
..

Fixed: https://github.com/nfs-ganesha/nfs-ganesha/issues/275

Change-Id: I4a44bca9b871dddb69e477c35f5201825dfaccaa
Signed-off-by: taoCH 
---
M src/FSAL/FSAL_RGW/handle.c
M src/FSAL/fsal_helper.c
2 files changed, 8 insertions(+), 2 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I4a44bca9b871dddb69e477c35f5201825dfaccaa
Gerrit-Change-Number: 403203
Gerrit-PatchSet: 1
Gerrit-Owner: CHEN TAO 
--
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] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-08 Thread TomK 

On 3/8/2018 8:42 AM, TomK wrote:
I take this comment back:

"I think the FreeIPA client is using it instead.  Thinking it's not an 
NFS Ganesha question at this point then."


If NFS Ganesha uses only some of the idmapd libraries, does this imply I 
should be looking at the NFS Ganesha configs to control how these users 
are displayed?


Cheers,
Tom


On 3/8/2018 2:38 AM, Malahal Naineni wrote:
Hmm.  When I change some configs in /etc/idmapd.conf on the client:

Nobody-User = nfsnobody
Nobody-Group = nfsnobody

server that connects to the NFS Ganesha cluster, I do see some changes 
and folders list as nfsnobody instead of nobody.  So that gave me the 
impression it's being used in some way.


Tried with it disabled and the result is the same, still listed as 
nobody for UID / GID.  I think the FreeIPA client is using it instead. 
Thinking it's not an NFS Ganesha question at this point then.


Cheers,
Tom

 >> Tried identical ifmapd.conf files on client and server but 
rpcidmapd tries to start the local copy of nfsd on the nfs Ganesha 
servers but that competes with


NFS Ganesha doesn't need rpcidmapd daemon running. So refrain from 
running the idmapd daemon. Ganesha uses idmapd libraries, so you 
should be good as long as you have the libraries installed (part of 
the nfs-utils package on RHEL, I think).


Regards, Malahal.

On Tue, Mar 6, 2018 at 9:15 PM, Tom > wrote:


    t...@my.dom is an ad user.   Nix.my.dom is a subdomain managed 
freeipa.


    Tried identical ifmapd.conf files on client and server but rpcidmapd
    tries to start the local copy of nfsd on the nfs Ganesha servers but
    that competes with nfs-Ganesha and won’t bind on port 2049.  So I
    need to change the port for the old nfs to 12049 etc to get the old
    nfs started so rpcidmapd can start on the Ganesha nfs servers.  They
    made it a dependency.

    That’s when things get messy.   I may try to uninstall the built in
    nfs packages but not sure if they will also pull out the rpcidmapd
    ones too.

    Cheers,
    Tom

    Sent from my iPhone

 > On Mar 6, 2018, at 9:00 AM, Daniel Gryniewicz > wrote:
 >
 > Based on the error messages, you client is not sending
    t...@nix.my.dom but is sending t...@my.dom@localdomain.  Something is
    mis-configured on the client.  Have you tried having identical
    (including case) idmapd.conf files on both the client and server?
 >
 > Idmap configuration has historically be very picky and hard to
    set up, and I'm far from an expert on it.
 >
 > Daniel
 >
 >> On 03/06/2018 08:24 AM, TomK wrote:
 >> Hey Guy's,
 >> Getting below message which in turn fails to list proper UID /
    GID on NFSv4 mounts from within an unprivileged account. All files
    show up with owner and group as nobody / nobody when viewed from the
    client.
 >> Wondering if anyone saw this and what the solution could be here?
 >> If not the right list, let me know please.
 >> [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e
    "/^$/d"
 >> [General]
 >> Verbosity = 7
 >> Domain = nix.my.dom
 >> [Mapping]
 >> [Translation]
 >> [Static]
 >> [UMICH_SCHEMA]
 >> LDAP_server = ldap-server.local.domain.edu
    
 >> LDAP_base = dc=local,dc=domain,dc=edu
 >> [root@client01 etc]#
 >> Mount looks like this:
 >> nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4

(rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80) 


    /var/log/messages
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type:
    uid value: t...@my.dom@localdomain timeout 600
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
    calling nsswitch->name_to_uid
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
    't...@my.dom@localdomain' domain 'nix.my.dom': resulting localname
    '(null)'
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
    't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
    nsswitch->name_to_uid returned -22
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
    final return value is -22
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
    calling nsswitch->name_to_uid
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
    'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody'
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
    nsswitch->name_to_uid returned 0
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
    final return value is 0
 >> Mar  6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type:
    gid

Re: [Nfs-ganesha-devel] nfsv3 client writing file gets Invalid argument on glusterfs with quota on

2018-03-08 Thread Daniel Gryniewicz 

On 03/07/2018 10:21 PM, Kinglong Mee wrote:

On 2018/3/7 21:10, Daniel Gryniewicz wrote:

On 03/06/2018 10:10 PM, Kinglong Mee wrote:

On 2018/3/7 10:59, Kinglong Mee wrote:

When using nfsv3 on glusterfs-3.13.1-1.el7.x86_64 and 
nfs-ganesha-2.6.0-0.2rc3.el7.centos.x86_64,
I gets strange "Invalid argument" when writing file.

1. With quota disabled;
nfs client mount nfs-ganesha share, and do 'll' in the testing directory.

2. Enable quota;
# getfattr -d -m . -e hex /root/rpmbuild/gvtest/nfs-ganesha/testfile92
getfattr: Removing leading '/' from absolute path names
# file: root/rpmbuild/gvtest/nfs-ganesha/testfile92
trusted.gfid=0xe2edaac0eca8420ebbbcba7e56bbd240
trusted.gfid2path.b3250af8fa558e66=0x3966313434352d653530332d343831352d396635312d3236633565366332633137642f7465737466696c653932
trusted.glusterfs.quota.9f1445ff-e503-4815-9f51-26c5e6c2c17d.contri.3=0x0201

Notice: testfile92 without trusted.pgfid xattr.


The trusted.pgfid will be created by the next name lookup; nameless lookup 
don't create it.


3. restart glusterfs volume by "gluster volume stop/start gvtest"


Restarting glusterfsd here cleanup all inode cache from memory;
after starting, inode of testfile92's parent is NULL.


4. echo somedata > testfile92


Because, nfs-ganesha and nfs client has cache for testfile92,
before write fops, no name lookup happens that trusted.pgfid is not created for 
testfile92.

Quota_writev call quota_build_ancestry building the ancestry in 
quota_check_limit,
but testfile92 doesn't contain trusted.pgfid, so that write fops failed with 
Invalid argument.

I have no idea of fixing this problem, any comments are welcome.



I think, ideally, Gluster would send an invalidate upcall under the 
circumstances, causing Ganesha do drop it's cached entry.


It doesn't work.
I try to restarting nfs-ganesha, and echo data to testfile92, the problem also 
exists.

After nfs-ganesha restart,
1. A GETATTR is send from nfs-client for the testfile92, ganesha translates it 
to nameless lookup.
2. A ACCESS gets attributes from nfs-ganesha's cache (cached by #1).
3. A SETATTR sets the testfile92's size to 0, ganesha translates it to setattr 
fop.
4. A WRITE also get Invalid argument error.

If ganesha drops its cache, nfs client may write file by filehandle;
ganesha lookup it by nameless lookup from glusterfs,
so that, trusted.pgfid isn't created too.

I think, a name lookup is needed for testfile92 after quota enable.

thanks,
Kinglong Mee



If a name lookup is needed, then gluster cannot provide NFS semantics in 
these circumstances.  NFS *requires* that access by handle continue to 
work once the client has a handle.  In fact, there's no way to get a 
name for this, since the name doesn't exist anywhere in the handle (by 
design, since a name is an attribute of a dirent, not of a handle/inode).


So, this likely is a bug in Gluster, and needs to be fixed there.  Would 
it be possible to enable quota globally at the start as a workaround?


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

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

2018-03-08 Thread TomK 

On 3/8/2018 2:38 AM, Malahal Naineni wrote:
Hmm.  When I change some configs in /etc/idmapd.conf on the client:

Nobody-User = nfsnobody
Nobody-Group = nfsnobody

server that connects to the NFS Ganesha cluster, I do see some changes 
and folders list as nfsnobody instead of nobody.  So that gave me the 
impression it's being used in some way.


Tried with it disabled and the result is the same, still listed as 
nobody for UID / GID.  I think the FreeIPA client is using it instead. 
Thinking it's not an NFS Ganesha question at this point then.


Cheers,
Tom

 >> Tried identical ifmapd.conf files on client and server but rpcidmapd 
tries to start the local copy of nfsd on the nfs Ganesha servers but 
that competes with


NFS Ganesha doesn't need rpcidmapd daemon running. So refrain from 
running the idmapd daemon. Ganesha uses idmapd libraries, so you should 
be good as long as you have the libraries installed (part of the 
nfs-utils package on RHEL, I think).


Regards, Malahal.

On Tue, Mar 6, 2018 at 9:15 PM, Tom > wrote:


t...@my.dom is an ad user.   Nix.my.dom is a subdomain managed freeipa.

Tried identical ifmapd.conf files on client and server but rpcidmapd
tries to start the local copy of nfsd on the nfs Ganesha servers but
that competes with nfs-Ganesha and won’t bind on port 2049.  So I
need to change the port for the old nfs to 12049 etc to get the old
nfs started so rpcidmapd can start on the Ganesha nfs servers.  They
made it a dependency.

That’s when things get messy.   I may try to uninstall the built in
nfs packages but not sure if they will also pull out the rpcidmapd
ones too.

Cheers,
Tom

Sent from my iPhone

 > On Mar 6, 2018, at 9:00 AM, Daniel Gryniewicz > wrote:
 >
 > Based on the error messages, you client is not sending
t...@nix.my.dom but is sending t...@my.dom@localdomain.  Something is
mis-configured on the client.  Have you tried having identical
(including case) idmapd.conf files on both the client and server?
 >
 > Idmap configuration has historically be very picky and hard to
set up, and I'm far from an expert on it.
 >
 > Daniel
 >
 >> On 03/06/2018 08:24 AM, TomK wrote:
 >> Hey Guy's,
 >> Getting below message which in turn fails to list proper UID /
GID on NFSv4 mounts from within an unprivileged account. All files
show up with owner and group as nobody / nobody when viewed from the
client.
 >> Wondering if anyone saw this and what the solution could be here?
 >> If not the right list, let me know please.
 >> [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e
"/^$/d"
 >> [General]
 >> Verbosity = 7
 >> Domain = nix.my.dom
 >> [Mapping]
 >> [Translation]
 >> [Static]
 >> [UMICH_SCHEMA]
 >> LDAP_server = ldap-server.local.domain.edu

 >> LDAP_base = dc=local,dc=domain,dc=edu
 >> [root@client01 etc]#
 >> Mount looks like this:
 >> nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4

(rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80)
/var/log/messages
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type:
uid value: t...@my.dom@localdomain timeout 600
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
calling nsswitch->name_to_uid
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
't...@my.dom@localdomain' domain 'nix.my.dom': resulting localname
'(null)'
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
nsswitch->name_to_uid returned -22
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
final return value is -22
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
calling nsswitch->name_to_uid
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody'
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
nsswitch->name_to_uid returned 0
 >> Mar  6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
final return value is 0
 >> Mar  6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type:
gid value: t...@my.dom@localdomain timeout 600
 >> Mar  6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid:
calling nsswitch->name_to_gid
 >> Mar  6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid:
nsswitch->name_to_gid returned -22
 >> Mar  6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid:
final return value is -22
 >> Mar 

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: gtest/test_close_latency: close latency microbenchmark

2018-03-08 Thread GerritHub 
>From Girjesh Rajoria :

Girjesh Rajoria has uploaded this change for review. ( 
https://review.gerrithub.io/403191


Change subject: gtest/test_close_latency: close latency microbenchmark
..

gtest/test_close_latency: close latency microbenchmark

gtest unit test that run close on single case, large loops
and bypass cases to find average latency of the calls.

Change-Id: Ief345df72404d797b8040d19c01dd3202a914a6a
Signed-off-by: Girjesh Rajoria 
---
M src/gtest/CMakeLists.txt
A src/gtest/test_close_latency.cc
2 files changed, 417 insertions(+), 0 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ief345df72404d797b8040d19c01dd3202a914a6a
Gerrit-Change-Number: 403191
Gerrit-PatchSet: 1
Gerrit-Owner: Girjesh Rajoria 
--
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