Re: [Nfs-ganesha-devel] nTI-RPC refcounting and locking

2017-01-16 Thread Matt Benjamin
It sounds like your change is a step in the direction of unifying CLNT and SVCXPRT handle structures. As we've discussed off-list, if you take on the project of unifying the actual handle structures, you get the lock consolidation for free. In any event, if rpc_dplx_rec contains a service han

Re: [Nfs-ganesha-devel] Request: I'm looking for good file system test programs

2017-01-16 Thread Kevin C.
Frank asked: What sorts of tests? My answer: I am hoping to benefit from the experience of this group since this group has spent much more time than I working with NFS-Ganesha (and perhaps other file systems). I hope that this group has identified useful tests (beside throughput tests). For ex

Re: [Nfs-ganesha-devel] [mdcache] unreachable directory

2017-01-16 Thread Daniel Gryniewicz
On 01/16/2017 03:08 PM, Swen Schillig wrote: > On Mo, 2017-01-16 at 10:52 -0500, Daniel Gryniewicz wrote: >> Hi, Swen. >> >> Looking through that log, the failures of unlink() are returned from >> the >> sub_fsal, not directly caused by MDCACHE, so it's whatever's >> underneath >> (GPFS, presumably

Re: [Nfs-ganesha-devel] [mdcache] unreachable directory

2017-01-16 Thread Swen Schillig
On Mo, 2017-01-16 at 10:52 -0500, Daniel Gryniewicz wrote: > Hi, Swen. > > Looking through that log, the failures of unlink() are returned from > the  > sub_fsal, not directly caused by MDCACHE, so it's whatever's > underneath  > (GPFS, presumably?) that's returning ENOTEMPTY: Hi Dan sorry for du

Re: [Nfs-ganesha-devel] nTI-RPC fds

2017-01-16 Thread Swen Schillig
On Mo, 2017-01-16 at 14:21 -0500, William Allen Simpson wrote: > Swen, your other very short patch fixes a problem with closing the > fd.  And that's a good thing.  But the underlying problem is that > we have multiple copies of the fd, and do not know whether it has > been closed. > > I'm thinkin

Re: [Nfs-ganesha-devel] nTI-RPC refcounting and locking

2017-01-16 Thread Swen Schillig
On Mo, 2017-01-16 at 13:53 -0500, William Allen Simpson wrote: > Swen, I've been looking at your patch, and it has some good ideas. > For some odd reason, I awoke at 1:30 am thinking about it, and > got up and wrote some code. > I never intended to give you sleepless nights :-) > I've taken anoth

Re: [Nfs-ganesha-devel] Request: I'm looking for good file system test programs

2017-01-16 Thread Frank Filz
> 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. What sorts of tests? There is the pjd-fstest test suite that tests POSIX c

[Nfs-ganesha-devel] Request: I'm looking for good file system test programs

2017-01-16 Thread Kevin C.
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

[Nfs-ganesha-devel] nTI-RPC fds

2017-01-16 Thread William Allen Simpson
Swen, your other very short patch fixes a problem with closing the fd. And that's a good thing. But the underlying problem is that we have multiple copies of the fd, and do not know whether it has been closed. I'm thinking that it would be best to have one copy, in the SVCXPRT, and have everybod

[Nfs-ganesha-devel] nTI-RPC refcounting and locking

2017-01-16 Thread William Allen Simpson
Swen, I've been looking at your patch, and it has some good ideas. For some odd reason, I awoke at 1:30 am thinking about it, and got up and wrote some code. I've taken another patch of mine, and added the SVCXPRT into the rpc_dplx_rec, eliminating the refcnt entirely (using the SVCXPRT). After a

Re: [Nfs-ganesha-devel] [mdcache] unreachable directory

2017-01-16 Thread Daniel Gryniewicz
Hi, Swen. Looking through that log, the failures of unlink() are returned from the sub_fsal, not directly caused by MDCACHE, so it's whatever's underneath (GPFS, presumably?) that's returning ENOTEMPTY: 16/01/2017 13:56:16 : epoch 587cb7dc : dhcp-9-244-58-137 : ganesha.nfsd-14293[work-26] mdca

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: [valgrind] Mem-leak: Free channel client memory.

2017-01-16 Thread GerritHub
>From Swen Schillig : Swen Schillig has uploaded a new change for review. ( https://review.gerrithub.io/343215 Change subject: [valgrind] Mem-leak: Free channel client memory. .. [valgrind] Mem-leak: Free channel client memory

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Don't do work in assert()

2017-01-16 Thread GerritHub
>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded a new change for review. ( https://review.gerrithub.io/343263 Change subject: Don't do work in assert() .. Don't do work in assert() Standard assert() is a no-op on rel

Re: [Nfs-ganesha-devel] create_export :FSAL :CRIT :RGW module: librgw init failed (-5)

2017-01-16 Thread Daniel Gryniewicz
The lack of verbosity is not Ganesha's fault; it only gets the single error code back from Ceph. Try turning up all your client related logging in your ceph.conf, and check it's logging? Daniel On 01/14/2017 03:02 PM, Alessandro De Salvo wrote: > Hi Daniel, > > indeed, this is the root cause,

[Nfs-ganesha-devel] [mdcache] unreachable directory

2017-01-16 Thread Swen Schillig
Dan while I was performing some simple tests to validate some of my code, I stumbled over some possible mdcache issue. Here's what I'm doing. (ganesha-2.5-dev9) I create the following directory structure mkdir -p /home/swen//d/c/def/g/h/i/j/ where /home/swen/ is the mount point for a [V