Re: [Nfs-ganesha-devel] avltree question

2017-03-09 Thread Malahal Naineni 
Based on my code reading, both those functions give the node matching
the key if one is present. _inf() will give a node that would be prev
of key and _sub() will give _next of key if key isn't present in the
tree. You should be able to call avltree_inf() and then call
avltree_next on the returned node (which should be same as
avltree_sub). You could also do avltree_sub() and then avltree_prev.

Regards, Malahal.

On Fri, Mar 10, 2017 at 6:30 AM, Frank Filz  wrote:
>> If node > key, we are going "left", so smaller values should be on the left 
>> side
>> of the tree for this to make sense, correct?
>
> Ok, the order of operands for the compare function and how that maps to res > 
> 0 makes for confusion... Now I get it...
>
> I have another question, I'm trying to understand what avltree_inf and 
> avltree_sup are supposed to accomplish.
>
> I have need of a function to find the nodes that would be on either side of a 
> particular key without inserting the key into the tree (at which point of 
> course one could get avltree_prev and avltree_next).
>
> Thanks
>
> Frank
>
>> Regards, Malahal.
>>
>> On Thu, Mar 9, 2017 at 6:35 AM, Frank Filz  wrote:
>> > Looking at the AVL code, I'm wondering what order it sorts in.
>> >
>> > I'm confused by the following code:
>> >
>> > while (node) {
>> > res = avl_dirent_hk_cmpf(node, key);
>> > if (res == 0)
>> > return node;
>> > if (res > 0)
>> > node = node->left;
>> > else
>> > node = node->right;
>> > }
>> >
>> > Given that the comparison functions return -1, 0, 1 for <, ==, >, it
>> > seems like it effectively sorts in reverse order.
>> >
>> > Is that correct, or am I confused how the tree works...
>> >
>> > Frank
>> >
>> >
>> >
>> > ---
>> > This email has been checked for viruses by Avast antivirus software.
>> > https://www.avast.com/antivirus
>> >
>> >
>> > --
>> >  Announcing the Oxford Dictionaries API! The API offers
>> > world-renowned dictionary content that is easy and intuitive to
>> > access. Sign up for an account today to start using our lexical data
>> > to power your apps and projects. Get started today and enter our
>> > developer competition.
>> > http://sdm.link/oxford
>> > ___
>> > Nfs-ganesha-devel mailing list
>> > Nfs-ganesha-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] avltree question

2017-03-09 Thread Frank Filz 
> If node > key, we are going "left", so smaller values should be on the left 
> side
> of the tree for this to make sense, correct?

Ok, the order of operands for the compare function and how that maps to res > 0 
makes for confusion... Now I get it...

I have another question, I'm trying to understand what avltree_inf and 
avltree_sup are supposed to accomplish.

I have need of a function to find the nodes that would be on either side of a 
particular key without inserting the key into the tree (at which point of 
course one could get avltree_prev and avltree_next).

Thanks

Frank

> Regards, Malahal.
> 
> On Thu, Mar 9, 2017 at 6:35 AM, Frank Filz  wrote:
> > Looking at the AVL code, I'm wondering what order it sorts in.
> >
> > I'm confused by the following code:
> >
> > while (node) {
> > res = avl_dirent_hk_cmpf(node, key);
> > if (res == 0)
> > return node;
> > if (res > 0)
> > node = node->left;
> > else
> > node = node->right;
> > }
> >
> > Given that the comparison functions return -1, 0, 1 for <, ==, >, it
> > seems like it effectively sorts in reverse order.
> >
> > Is that correct, or am I confused how the tree works...
> >
> > Frank
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> >
> > --
> >  Announcing the Oxford Dictionaries API! The API offers
> > world-renowned dictionary content that is easy and intuitive to
> > access. Sign up for an account today to start using our lexical data
> > to power your apps and projects. Get started today and enter our
> > developer competition.
> > http://sdm.link/oxford
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] UDP duplicate cache in both Ganesha and ntirpc?

2017-03-09 Thread William Allen Simpson 
On 3/9/17 10:12 AM, Daniel Gryniewicz wrote:
> It probably should stay.  ntirpc is intended to be useful to more than
> Ganesha, and this seems like a useful feature for potential users.  It's
> not the codepaths called by Ganesha, so it doesn't cause any problems.
>
It *is* the codepaths called by Ganesha:

svc_dg_recv(struct svc_req *req)
{
[...]
 req->rq_cksum =
#if 1
 CityHash64WithSeed(iov.iov_base, MIN(256, iov.iov_len), 103);
#else
 calculate_crc32c(0, iov.iov_base, MIN(256, iov.iov_len));
#endif

 if (su->su_cache != NULL) {
 if (svc_dg_cache_get(xprt, >rq_msg, , )) {

[...]

svc_dg_reply(struct svc_req *req)
{
[...]
 if (sendmsg(xprt->xp_fd, msg, 0) == (ssize_t) slen) {
 stat = true;
 if (su->su_cache)
 svc_dg_cache_set(xprt, slen,
  req->rq_msg.rm_xid);
 }


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] dispatch queues

2017-03-09 Thread Matt Benjamin 
Hi Bill,

- Original Message -
> From: "William Allen Simpson" 
> To: "NFS Ganesha Developers" 
> Sent: Thursday, March 9, 2017 2:44:29 AM
> Subject: Re: [Nfs-ganesha-devel] dispatch queues
> 
> On 3/8/17 5:34 AM, William Allen Simpson wrote:
> > Ganesha currently has 2 phases of dispatch queuing: one for input and
> > decoding, then another for executing/encoding output.  (I've fixed the
> > third queue for later sending the output, where the thread should stay
> > hot as long as there's more to process.)
> >
> > On Monday, Matt told me we were having problems with sequential IO.
> > Wishing that somebody had mentioned this to me sooner.
> >
> > [...]
> >
> After a somewhat loud discussion with Matt, we've agreed on a
> different approach.  This will also be useful for fully async IO
> that is planned for V2.6.

Um, I don't think this statement represents either of the two internal meetings 
we had accurately, but ok.

> 
> The sequential IO reports were from specific .

For posterity, the feedback I've seen regarding sequential i/o was provided by 
upstream folks on our regular concall. nobody uses the term "customer" on this 
list, for obvious reasons.

> 
> I'm going to code something more like Weighted Fair Queuing that
> I've mentioned on this list back in June 2015.  The only weight is
> that we want any initial TCP connection to be handled as rapidly as
> possible to get the standard TCP slow start moving.
> 
> Are there other priorities that we should handle?
> 
> Otherwise, we really need a more even handed approach across large
> numbers of clients, keeping each client's requests in strict order,
> even though some of them could be "faster" than others.  The fair
> queuing should also help prevent traffic spikes.
> 
> I think I can have something coded by next week.  I'd already done
> some preliminary work in 2015.  But the time constraint means this
> will be pretty bare bones for V2.5.

Well, as I think we've all agreed, nothing like this is going into 2.5.  
Anything that DOES make it to the nfs-ganesha upstream is going to need to be 
well motivated, well measured, and matured.

> 
> To really do a good job, we need some kind of FSAL feedback API.
> I'm going to ask the Gluster folks for some help on designing it, so
> that we have a good use case and testing infrastructure.  But we'll
> post the design iterations here in the same fashion as an IETF
> Working Group, so that maybe we can get other FSAL feedback, too.
> 
> Is anybody specifically interested in helping design the API?

As the proposer of this idea, I'm interested in seeing experimental prototypes 
that help us establish and refine something that works.  Let's post running 
code, and then write specs.

That said, upstream participation is welcome.

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

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] UDP duplicate cache in both Ganesha and ntirpc?

2017-03-09 Thread Daniel Gryniewicz 
It probably should stay.  ntirpc is intended to be useful to more than 
Ganesha, and this seems like a useful feature for potential users.  It's 
not the codepaths called by Ganesha, so it doesn't cause any problems.

Daniel

On 03/09/2017 09:21 AM, William Allen Simpson wrote:
> Anybody have any objections to my removing the ntirpc version?
>
> Clearly, this is done in RPCAL/nfs_duprec.c, so why is it also in
> libntirpc/src/svc_dg.c?
>
> According to blame, Matt, Malahal, and Frank have all worked on this,
> but not since early 2015.
>
> --
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] dispatch queues

2017-03-09 Thread Daniel Gryniewicz 
On 03/09/2017 02:44 AM, William Allen Simpson wrote:
> On 3/8/17 5:34 AM, William Allen Simpson wrote:
>> Ganesha currently has 2 phases of dispatch queuing: one for input and
>> decoding, then another for executing/encoding output.  (I've fixed the
>> third queue for later sending the output, where the thread should stay
>> hot as long as there's more to process.)
>>
>> On Monday, Matt told me we were having problems with sequential IO.
>> Wishing that somebody had mentioned this to me sooner.
>>
>> [...]
>>
> After a somewhat loud discussion with Matt, we've agreed on a
> different approach.  This will also be useful for fully async IO
> that is planned for V2.6.
>
> The sequential IO reports were from specific customers.  Since I'm
> not in direct contact with customers I'm not hearing about it.  But
> we should be able to get field confirmation about whether the new
> approach is working better
>
> I'm going to code something more like Weighted Fair Queuing that
> I've mentioned on this list back in June 2015.  The only weight is
> that we want any initial TCP connection to be handled as rapidly as
> possible to get the standard TCP slow start moving.
>
> Are there other priorities that we should handle?

How does WFQ get us closer to Async I/O?  I'm not seeing the connection, 
so could you elaborate on this?

> Otherwise, we really need a more even handed approach across large
> numbers of clients, keeping each client's requests in strict order,
> even though some of them could be "faster" than others.  The fair
> queuing should also help prevent traffic spikes.
>
> I think I can have something coded by next week.  I'd already done
> some preliminary work in 2015.  But the time constraint means this
> will be pretty bare bones for V2.5.

I disagree with this.  Nothing as invasive as queuing changes should go 
into 2.5.  2.5 should get the dirent chunking and bug fixes only at this 
point.

Daniel

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] UDP duplicate cache in both Ganesha and ntirpc?

2017-03-09 Thread Matt Benjamin 
Hi Bill,

As I explained in detail, this code path is used in svc_run, but nfs-ganesha 
doesn't use it.

Matt

- Original Message -
> From: "William Allen Simpson" 
> To: "NFS Ganesha Developers" 
> Sent: Thursday, March 9, 2017 9:21:38 AM
> Subject: [Nfs-ganesha-devel] UDP duplicate cache in both Ganesha and ntirpc?
> 
> Anybody have any objections to my removing the ntirpc version?
> 
> Clearly, this is done in RPCAL/nfs_duprec.c, so why is it also in
> libntirpc/src/svc_dg.c?
> 
> According to blame, Matt, Malahal, and Frank have all worked on this,
> but not since early 2015.
> 
> --
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> ___
> 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

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Permission denied error with Kerberos enabled

2017-03-09 Thread Satya Prakash GS 
Looks like the gen field in svc_rpc_gss_data is used to check the
freshness of a context. However it is not initialized to axp->gen in
authgss_ctx_hash_set.
Will this not result in evicting the entries out early or am I missing
something ?

Thanks,
Satya.


On Tue, Mar 7, 2017 at 4:36 PM, Satya Prakash GS
 wrote:
>>On 3/7/17 4:56 AM, William Allen Simpson wrote:
>> On 3/6/17 6:58 PM, Matt Benjamin wrote:
>>> Looking briefly at section 5.3.3.3 of rfc2203, it seems like that would be 
>>> correct.  If the client has just refreshed its credentials, why is it 
>>> continuing to send with the expired context?
>>>
>
> Thank you for the reply.
>
> The client may not be sending expired credentials but it is supposed
> to reestablish the credentials using
> RPC_GSS_PROC_DESTROY/RPC_GSS_PROC_INIT which I guess is not happening.
> I am continuing to debug this further.
>
> As per the RFC, Ganesha is supposed to be throwing AUTH_REJECTEDCRED
> instead of RPCSEC_GSS_CREDPROBLEM when it doesn't find credentials in
> the cache.
>
> However the nfs client handles AUTH_REJECTEDCRED,
> RPCSEC_GSS_CREDPROBLEM similarly. I am not hopeful of this change but
> I can give it a try.
>
>> I don't know, but I'll take a look.  Now that we always have a server
>> for a client, perhaps the cache can be moved into a shared structure?
>
>>Sorry, thought that was our ntirpc client.  Looking back, that's the
>>kernel client.  Not much we can do about the kernel client other than
>>report a bug.
>
> William,
> I want to be sure it's a client bug and not Ganesha bug before putting
> it on the kernel mailing list. Given that the issue is reproducible
> twice/thrice a week I am wondering how it would have gone unreported
> so far.
>
> Regards,
> Satya.
>
>
>
> On Tue, Mar 7, 2017 at 5:28 AM, Matt Benjamin  wrote:
>> Hi Satya,
>>
>> Looking briefly at section 5.3.3.3 of rfc2203, it seems like that would be 
>> correct.  If the client has just refreshed its credentials, why is it 
>> continuing to send with the expired context?
>>
>> Matt
>>
>> - Original Message -
>>> From: "Satya Prakash GS" 
>>> To: nfs-ganesha-devel@lists.sourceforge.net
>>> Sent: Monday, March 6, 2017 1:10:36 PM
>>> Subject: Re: [Nfs-ganesha-devel] Permission denied error with Kerberos  
>>>   enabled
>>>
>>> With libntirpc debugs enabled I could see all the three retries are
>>> failing because of the unavailability of the creds in the cache. The
>>> credentials are being removed by the reaper in the authgss_ctx_gc_idle
>>> because of this condition -
>>> abs(axp->gen - gd->gen) > __svc_params->gss.max_idle_gen
>>>
>>> >From the code, I can see that only a further RPCSEC_GSS_INIT call from
>>> the client can repopulate the credentials in the cache. I am not sure
>>> how server can dictate client to establish the context again.
>>>
>>> Any help is appreciated.
>>>
>>> Thanks,
>>> Satya.
>>>
>>> On Wed, Mar 1, 2017 at 7:35 PM, Satya Prakash GS
>>>  wrote:
>>> > Hi,
>>> >
>>> > I am seeing "Permission denied" errors while running iozone on nfs
>>> > client with kerberos enabled. Digging further, I found there are a lot
>>> > of AUTH_REJECTEDCRED messages in nfs server log. NFS client tolerates
>>> > 2 errors from server and tries to refresh the credentials. On the
>>> > third call it would throw an error to the application.
>>> >
>>> > http://lxr.free-electrons.com/source/net/sunrpc/clnt.c#L2343
>>> >
>>> > 2395 switch ((n = ntohl(*p++))) {
>>> > 2396 case RPC_AUTH_REJECTEDCRED:
>>> > 2397 case RPC_AUTH_REJECTEDVERF:
>>> > 2398 case RPCSEC_GSS_CREDPROBLEM:
>>> > 2399 case RPCSEC_GSS_CTXPROBLEM:
>>> > 2400 if (!task->tk_cred_retry)
>>> > 2401 break;
>>> > 2402 task->tk_cred_retry--;
>>> > 2403 dprintk("RPC: %5u %s: retry stale creds\n",
>>> > 2404 task->tk_pid, __func__);
>>> > 2405 rpcauth_invalcred(task);
>>> >
>>> >
>>> > On the client I have seen this message twice :
>>> >
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 call_status (status 20)
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 call_decode (status 20)
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 rpc_verify_header: retry
>>> > stale creds
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 invalidating RPCSEC_GSS
>>> > cred 880544ce4600
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 release request
>>> > 8804062e7000
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 call_reserve (status 0)
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 failed to lock transport
>>> > 8808723c5800
>>> > Feb 26 10:27:01 atsqa6c71 kernel: RPC: 39431 sleep_on(queue
>>> > "xprt_sending" time 25264836677)
>>> > Feb 26 10:27:01 atsqa6c71 kernel:

[Nfs-ganesha-devel] UDP duplicate cache in both Ganesha and ntirpc?

2017-03-09 Thread William Allen Simpson 
Anybody have any objections to my removing the ntirpc version?

Clearly, this is done in RPCAL/nfs_duprec.c, so why is it also in
libntirpc/src/svc_dg.c?

According to blame, Matt, Malahal, and Frank have all worked on this,
but not since early 2015.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
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]: config_samples: fix typo in config block name

2017-03-09 Thread GerritHub 
>From Ramana Raja :

Ramana Raja has uploaded this change for review. ( 
https://review.gerrithub.io/352054


Change subject: config_samples: fix typo in config block name
..

config_samples: fix typo in config block name

Change-Id: I123dab91583379d191933363c7e99b0946a6b913
Signed-off-by: Ramana Raja 
---
M src/config_samples/config.txt
1 file changed, 3 insertions(+), 3 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I123dab91583379d191933363c7e99b0946a6b913
Gerrit-Change-Number: 352054
Gerrit-PatchSet: 1
Gerrit-Owner: Ramana Raja 
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
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]: FSAL_RGW: fixup fsid for bucket export

2017-03-09 Thread GerritHub 
>From Gui Hecheng :

Gui Hecheng has uploaded this change for review. ( 
https://review.gerrithub.io/351984


Change subject: FSAL_RGW: fixup fsid for bucket export
..

FSAL_RGW: fixup fsid for bucket export

When do lookup_path() on a bucket export, we use the fsid in
filehandle of root directory(/) as export fsid, actually we
should use the fsid of the root filehandle, which is a separate
thing.
This fixes automount problem together with ceph commit:
rgw_file:  fix fs_inst progression
0e988edfb6ab9085d6d37cfc444d46e8a2841943

Change-Id: I919fb7f03aae58d19261fe10e5f6acdb1ddb134e
Signed-off-by: guihecheng 
---
M src/FSAL/FSAL_RGW/export.c
1 file changed, 9 insertions(+), 1 deletion(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I919fb7f03aae58d19261fe10e5f6acdb1ddb134e
Gerrit-Change-Number: 351984
Gerrit-PatchSet: 1
Gerrit-Owner: Gui Hecheng 
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] conf call beeping

2017-03-09 Thread Supriti Singh 
I guess it was me who was causing beep in the last call. 

Like Kaleb, I was also trying to connect to 5695731261 using my iphone app.
And dialing into 373354489/6397 from the same app, solved the issue.

So, it seems 5695731261 is the culprit here.


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



>>> "Frank Filz"  03/08/17 7:06 PM >>>
> On 03/08/2017 11:35 AM, Daniel Gryniewicz wrote:
> > Firefox works if you have a new enough version (I use 50.1.0, but
> > supposedly 50.x or higher works).  Alternatively, chrome works.
> >
> > On Tue, Mar 7, 2017 at 3:45 PM, Frank Filz  wrote:
> >> On 03/07/2017 08:46 AM, LUCAS Patrice wrote:
> >>> Hi everybody,
> >>>
> >>>
> >>> We really need to find who is beeping by trying to connect to the
> >>> conf call. It's really impossible to hear or understand something by
> >>> phone with this beep.
> >>>
> >>>
> >>> Regards,
> >>>
> >> It seems like folks trying to connect via dial in may be the cause of
> >> the beeping issues.
> 
> Who else causes it?  I didn't dial in yesterday, so if it happened
yesterday
> then someone else was the culprit.
> 
> When I was the culprit, I used the Mac app and was connecting to
> 5695731261. Using the same Mac, same app, dialing into 373354489/6397
> didn't cause it.

Yea, I wonder if using 5695731261 is the culprit...

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel



--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel