[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: FSAL_GLUSTER : Avoid double free for glfsal_module

2016-09-14 Thread GerritHub 
>From Jiffin Tony Thottan :

Jiffin Tony Thottan has uploaded a new change for review.

  https://review.gerrithub.io/294623

Change subject: FSAL_GLUSTER : Avoid double free for glfsal_module
..

FSAL_GLUSTER : Avoid double free for glfsal_module

If FSAL_GLUSTER fails to load it will free glfsal_module in glusterfs_init.
Since load_fsal() got failed, a clean up should be performed and as a part
of that glusterfs_unload() got executed. Finally it will end up in a double
free for glfsal_module

Change-Id: I593dbb43b45d61d5a78333b330c7e57c9d3219ef
Signed-off-by: Jiffin Tony Thottan 
---
M src/FSAL/FSAL_GLUSTER/main.c
1 file changed, 1 insertion(+), 0 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I593dbb43b45d61d5a78333b330c7e57c9d3219ef
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Jiffin Tony Thottan 

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] NLM async locking

2016-09-14 Thread Frank Filz 
> Hi Frank,
> Are you going to push the patch you asked me to test ?

Pushed:

https://review.gerrithub.io/294605

Frank

> From:   "Frank Filz" 
> To: Marc Eshel/Almaden/IBM@IBMUS
> Cc: "'nfs-ganesha-devel'" 
> Date:   09/07/2016 04:18 PM
> Subject:RE: [Nfs-ganesha-devel] NLM async locking
> 
> 
> 
> I changed it so we don't take the lock off the list when it find the
blocked lock
> entry in the blocked lock list.
> 
> It then removes it from the list only if sending the async grant succeeds.
> 
> It probably needs some tweaking, but it SHOULD help.
> 
> Frank
> 
> > -Original Message-
> > From: Marc Eshel [mailto:es...@us.ibm.com]
> > Sent: Wednesday, September 7, 2016 4:11 PM
> > To: Frank Filz 
> > Cc: 'nfs-ganesha-devel' 
> > Subject: RE: [Nfs-ganesha-devel] NLM async locking
> >
> > Just looking at the code I don't see where you retry the lock request
> from
> > the FSAL which is required to add it back to the FSAL queue.
> > Am I missing something?
> > Marc.
> >
> >
> >
> > From:   "Frank Filz" 
> > To: Marc Eshel/Almaden/IBM@IBMUS
> > Cc: "'nfs-ganesha-devel'" 
> > Date:   09/07/2016 03:57 PM
> > Subject:RE: [Nfs-ganesha-devel] NLM async locking
> >
> >
> >
> > Marc,
> >
> > Could you try the top commit in this branch:
> >
> > https://github.com/ffilz/nfs-ganesha/commits/async
> >
> > It may not be the complete solution, but I think it will help your
> > scenario.
> >
> > I need to do more work on async blocking locks...
> >
> > And it looks like without async blocking lock support, Ganesha doesn't
> > handle the case where a lock blocks on a conflicting lock from outside
> the
> > Ganesha instance. I will be looking at implementing my thread pool
> > idea that I modeled in the multilock tool.
> >
> > Frank
> >
> > > -Original Message-
> > > From: Frank Filz [mailto:ffilz...@mindspring.com]
> > > Sent: Wednesday, September 7, 2016 9:42 AM
> > > To: 'Marc Eshel' 
> > > Cc: 'nfs-ganesha-devel' 
> > > Subject: Re: [Nfs-ganesha-devel] NLM async locking
> > >
> > > Ok, I'm not sure this ever worked right...
> > >
> > > With the lock available upcall, we never put the lock back on the
> > blocked
> > lock
> > > list if an attempt to acquire the lock from the FSAL fails...
> > >
> > > So the way the lock available upcall is supposed to work:
> > >
> > > Client requests conflicting lock
> > > Blocked lock gets registered by FSAL SAL puts lock on blocked lock
> > > list Time passes FSAL makes lock available upcall SAL finds the
> > > blocked lock entry in the blocked lock list SAL makes a
> > call
> > to
> > > FSAL to attempt to acquire the lock Assume that fails (in the
> > > example, because multiple conflicting locks got
> > > notified)
> > > SAL puts the lock BACK on the blocked lock list (this step is
> > > missing)
> > and
> > all is
> > > well
> > > Time passes
> > > FSAL makes lock available upcall
> > > SAL finds the blocked lock entry in the blocked lock list SAL makes
> > > a
> > call
> > to
> > > FSAL to attempt to acquire the lock Lock is granted by FSAL SAL
> > > makes
> > async
> > > call back to client If THAT fails, SAL releases the lock from the
> > > FSAL
> > and
> > > disposes of the lock entry and all is well If THAT succeeds, the
> > > lock
> is
> > > completely granted and all is well
> > >
> > > I also see that if the client retries the lock before it is granted,
> we
> > don't
> > > remove the lock entry from the blocked lock list... I don't think
> > > that
> > will ever
> > > cause a problem but we should clean that up also...
> > >
> > > Let me try a patch to fix...
> > >
> > > Frank
> > >
> > > > -Original Message-
> > > > From: Marc Eshel [mailto:es...@us.ibm.com]
> > > > Sent: Tuesday, September 6, 2016 9:34 PM
> > > > To: Frank Filz 
> > > > Cc: 'nfs-ganesha-devel' 
> > > > Subject: RE: NLM async locking
> > > >
> > > > Did you get a chance to look at this problem?
> > > > Marc.
> > > >
> > > >
> > > >
> > > > From:   "Frank Filz" 
> > > > To: Marc Eshel/Almaden/IBM@IBMUS
> > > > Cc: "'nfs-ganesha-devel'"
> > 
> > > > Date:   08/29/2016 02:37 PM
> > > > Subject:RE: NLM async locking
> > > >
> > > >
> > > >
> > > > > I see the following failure:
> > > > > 1. Get conflicting locks from 3 clients
> > > > > cli 1 gets 0-100
> > > > > cli 2 is blocked on 0-1000
> > > > > cli 3 is blocked on 0-1
> > > > > 2. cli 1 unlocks
> > > > > up-call for cli 2 and 3 to retry
> > > > > cli 2 gets 0-1000
> > > > > cli 3 is blocked on 0-1000
> > > > > 3. cli 2 unlocks
> > > > > up-call for cli 3 but Ganesha

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add a thread to poll blocked locks

2016-09-14 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review.

  https://review.gerrithub.io/294609

Change subject: Add a thread to poll blocked locks
..

Add a thread to poll blocked locks

If the FSAL doesn't support async blocked locks, we must poll the
blocked locks on some interval.

To implement this, we need the following:

1. A thread to poll
2. A config variable to define the polling interval
3. do_lock_op must track if a LOCKB request was made to an FSAL that
   doesn't support async blocking locks, and in that case, it will
   return STATE_LOCK_BLOCKED instead of STATE_LOCK_CONFLICT. We still
   translate the LOCKB request to a LOCK request to the FSAL.
4. The polling thread will try_to_grant_lock with a new grant type,
   STATE_GRANT_POLL (though in fact, the action for this is identical
   to STATE_GRANT_FSAL_AVAILABLE).

Incidental changes:

We track the type of blocked lock:
INTERNAL (is blocked on another lock managed by this Ganesha instance)
ASYNC (is managed by FSAL async blocking)
POLL (will be polled by the new thread)

This allows the polling thread to easily skip the blocked locks that
will not be relevant. It also allows us to indicate the type of block
when displaying lock entries.

Change-Id: I502cc8757ef1132301b73393d5fbefa19ab485df
Signed-off-by: Frank S. Filz 
---
M src/MainNFSD/nfs_init.c
M src/SAL/state_async.c
M src/SAL/state_lock.c
M src/config_samples/config.txt
M src/include/gsh_config.h
M src/include/sal_data.h
M src/include/sal_functions.h
M src/support/nfs_read_conf.c
8 files changed, 205 insertions(+), 29 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I502cc8757ef1132301b73393d5fbefa19ab485df
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 

--
___
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]: multilock: Actually send OFD/POSIX parameter to ml client

2016-09-14 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review.

  https://review.gerrithub.io/294606

Change subject: multilock: Actually send OFD/POSIX parameter to ml client
..

multilock: Actually send OFD/POSIX parameter to ml client

Change-Id: Ib60c0b4a5fd396dc17654dc338f5c6f6fca62249
Signed-off-by: Frank S. Filz 
---
M src/tools/multilock/ml_functions.c
1 file changed, 14 insertions(+), 0 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib60c0b4a5fd396dc17654dc338f5c6f6fca62249
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 

--
___
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_PROXY does not support locks

2016-09-14 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review.

  https://review.gerrithub.io/294607

Change subject: FSAL_PROXY does not support locks
..

FSAL_PROXY does not support locks

Change-Id: Ife4a60d27799b18a96e616c62bb1c7c6d06805e1
Signed-off-by: Frank S. Filz 
---
M src/FSAL/FSAL_PROXY/main.c
1 file changed, 1 insertion(+), 1 deletion(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ife4a60d27799b18a96e616c62bb1c7c6d06805e1
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 

--
___
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_VFS: Don't lose rc from lock call when doing getlock fo...

2016-09-14 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review.

  https://review.gerrithub.io/294608

Change subject: FSAL_VFS: Don't lose rc from lock call when doing getlock for 
conflict
..

FSAL_VFS: Don't lose rc from lock call when doing getlock for conflict

Change-Id: I1e7fddf8cd26b433b49510eb55c914816f3e8ff8
Signed-off-by: Frank S. Filz 
---
M src/FSAL/FSAL_VFS/file.c
1 file changed, 2 insertions(+), 2 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I1e7fddf8cd26b433b49510eb55c914816f3e8ff8
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 

--
___
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]: Rename config_samples/logging..txt -> config_samples/logging...

2016-09-14 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review.

  https://review.gerrithub.io/294610

Change subject: Rename config_samples/logging..txt -> config_samples/logging.txt
..

Rename config_samples/logging..txt -> config_samples/logging.txt

Change-Id: Ib42954cc797d7b72ef92c28dce23d3b920019745
Signed-off-by: Frank S. Filz 
---
R src/config_samples/logging.txt
1 file changed, 0 insertions(+), 0 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib42954cc797d7b72ef92c28dce23d3b920019745
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 

--
___
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]: Fix STATE_GRANT_FSAL_AVAILABLE upcall

2016-09-14 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review.

  https://review.gerrithub.io/294605

Change subject: Fix STATE_GRANT_FSAL_AVAILABLE upcall
..

Fix STATE_GRANT_FSAL_AVAILABLE upcall

Don't remove locks from the blocked lock list until a grant has successfully
been sent or has failed.

Change-Id: I1eec2059e951f45a644770a07fd38fee4b8fd099
Signed-off-by: Frank S. Filz 
---
M src/SAL/state_lock.c
1 file changed, 18 insertions(+), 2 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I1eec2059e951f45a644770a07fd38fee4b8fd099
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] NLM async locking

2016-09-14 Thread Frank Filz 
Yes, will be pushing it shortly.

Have several other patches, including now polling blocked locks on FSALs
that don't support async blocking locks.

Frank

> -Original Message-
> From: Marc Eshel [mailto:es...@us.ibm.com]
> Sent: Wednesday, September 14, 2016 4:03 PM
> To: Marc Eshel 
> Cc: Frank Filz ; 'nfs-ganesha-devel'
 de...@lists.sourceforge.net>
> Subject: Re: [Nfs-ganesha-devel] NLM async locking
> 
> Hi Frank,
> Are you going to push the patch you asked me to test ?
> Thanks, Marc.
> 
> 
> 
> 
> 
> From:   "Frank Filz" 
> To: Marc Eshel/Almaden/IBM@IBMUS
> Cc: "'nfs-ganesha-devel'" 
> Date:   09/07/2016 04:18 PM
> Subject:RE: [Nfs-ganesha-devel] NLM async locking
> 
> 
> 
> I changed it so we don't take the lock off the list when it find the
blocked lock
> entry in the blocked lock list.
> 
> It then removes it from the list only if sending the async grant succeeds.
> 
> It probably needs some tweaking, but it SHOULD help.
> 
> Frank
> 
> > -Original Message-
> > From: Marc Eshel [mailto:es...@us.ibm.com]
> > Sent: Wednesday, September 7, 2016 4:11 PM
> > To: Frank Filz 
> > Cc: 'nfs-ganesha-devel' 
> > Subject: RE: [Nfs-ganesha-devel] NLM async locking
> >
> > Just looking at the code I don't see where you retry the lock request
> from
> > the FSAL which is required to add it back to the FSAL queue.
> > Am I missing something?
> > Marc.
> >
> >
> >
> > From:   "Frank Filz" 
> > To: Marc Eshel/Almaden/IBM@IBMUS
> > Cc: "'nfs-ganesha-devel'" 
> > Date:   09/07/2016 03:57 PM
> > Subject:RE: [Nfs-ganesha-devel] NLM async locking
> >
> >
> >
> > Marc,
> >
> > Could you try the top commit in this branch:
> >
> > https://github.com/ffilz/nfs-ganesha/commits/async
> >
> > It may not be the complete solution, but I think it will help your
> > scenario.
> >
> > I need to do more work on async blocking locks...
> >
> > And it looks like without async blocking lock support, Ganesha doesn't
> > handle the case where a lock blocks on a conflicting lock from outside
> the
> > Ganesha instance. I will be looking at implementing my thread pool
> > idea that I modeled in the multilock tool.
> >
> > Frank
> >
> > > -Original Message-
> > > From: Frank Filz [mailto:ffilz...@mindspring.com]
> > > Sent: Wednesday, September 7, 2016 9:42 AM
> > > To: 'Marc Eshel' 
> > > Cc: 'nfs-ganesha-devel' 
> > > Subject: Re: [Nfs-ganesha-devel] NLM async locking
> > >
> > > Ok, I'm not sure this ever worked right...
> > >
> > > With the lock available upcall, we never put the lock back on the
> > blocked
> > lock
> > > list if an attempt to acquire the lock from the FSAL fails...
> > >
> > > So the way the lock available upcall is supposed to work:
> > >
> > > Client requests conflicting lock
> > > Blocked lock gets registered by FSAL SAL puts lock on blocked lock
> > > list Time passes FSAL makes lock available upcall SAL finds the
> > > blocked lock entry in the blocked lock list SAL makes a
> > call
> > to
> > > FSAL to attempt to acquire the lock Assume that fails (in the
> > > example, because multiple conflicting locks got
> > > notified)
> > > SAL puts the lock BACK on the blocked lock list (this step is
> > > missing)
> > and
> > all is
> > > well
> > > Time passes
> > > FSAL makes lock available upcall
> > > SAL finds the blocked lock entry in the blocked lock list SAL makes
> > > a
> > call
> > to
> > > FSAL to attempt to acquire the lock Lock is granted by FSAL SAL
> > > makes
> > async
> > > call back to client If THAT fails, SAL releases the lock from the
> > > FSAL
> > and
> > > disposes of the lock entry and all is well If THAT succeeds, the
> > > lock
> is
> > > completely granted and all is well
> > >
> > > I also see that if the client retries the lock before it is granted,
> we
> > don't
> > > remove the lock entry from the blocked lock list... I don't think
> > > that
> > will ever
> > > cause a problem but we should clean that up also...
> > >
> > > Let me try a patch to fix...
> > >
> > > Frank
> > >
> > > > -Original Message-
> > > > From: Marc Eshel [mailto:es...@us.ibm.com]
> > > > Sent: Tuesday, September 6, 2016 9:34 PM
> > > > To: Frank Filz 
> > > > Cc: 'nfs-ganesha-devel' 
> > > > Subject: RE: NLM async locking
> > > >
> > > > Did you get a chance to look at this problem?
> > > > Marc.
> > > >
> > > >
> > > >
> > > > From:   "Frank Filz" 
> > > > To: Marc Eshel/Almaden/IBM@IBMUS
> > > > Cc: "'nfs-ganesha-devel'"
> > 
> > > > Date:   08/29/2016 02:37 PM
> > > > Subject:RE: NLM async locking
> >

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: NFSv4 Use correct fileid for readdir

2016-09-14 Thread GerritHub 
>From Frank Filz :

Frank Filz has uploaded a new change for review.

  https://review.gerrithub.io/294597

Change subject: NFSv4 Use correct fileid for readdir
..

NFSv4 Use correct fileid for readdir

Change-Id: I2aa8a53a5007002dc180841134a3b29d983420a4
Signed-off-by: Frank S. Filz 
---
M src/Protocols/NFS/nfs4_op_readdir.c
1 file changed, 2 insertions(+), 2 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I2aa8a53a5007002dc180841134a3b29d983420a4
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 

--
___
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]: Fix clock_gettime error handling in ceph_setattr2

2016-09-14 Thread GerritHub 
>From :

jlay...@redhat.com has uploaded a new change for review.

  https://review.gerrithub.io/294566

Change subject: Fix clock_gettime error handling in ceph_setattr2
..

Fix clock_gettime error handling in ceph_setattr2

Any error there will be in errno, and it is a POSIX call so we want to
use posix2fsal_error.

Change-Id: I1024a775680df63e5598dc17278b42f1a440acdb
Signed-off-by: Jeff Layton 
---
M src/FSAL/FSAL_CEPH/handle.c
1 file changed, 4 insertions(+), 4 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I1024a775680df63e5598dc17278b42f1a440acdb
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: jlay...@redhat.com

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Threading models and the thread fridge

2016-09-14 Thread Daniel Gryniewicz 
Bill has some ideas and some outstanding (although outdated) work on 
consolidating and cleaning up the fridge.  Bill, can you post a short 
description of your ideas on that?

Daniel

On 09/14/2016 12:42 PM, Frank Filz wrote:
> While looking at adding a thread to handle NLM blocked lock polling on FSALs
> that don't support async blocking locks, I noticed there's a lot of
> complexity in the thread fridge and a lot of different users each with their
> own pool (some pools with only 1 thread).
>
> I think it might be worth examining how we use the thread fridge and look
> for ways to simplify it, and also make sure we are making the best use of
> threads.
>
> We have a number of uses of a "worker thread" model where a pool of threads
> looks on a queue for work to do. One question is if every one of these uses
> needs its own queue. The nfs_worker_thread threads probably do benefit from
> being their own pool and queue, but do all the other uses.
>
> Then there are some threads that wake up periodically to do work that is not
> exactly queued (the reaper thread for example). It's not clear if these
> threads avoid any wakeup at all If there is not any work to be done.
>
> Then there are some threads that live to sit blocked on some system call to
> wait for work to do. These threads particularly don't make sense to be in a
> thread pool unless they block intermittently (for example the proposed
> threads to actually block on locks). For shutdown purposes, we need to
> examine if any of these threads is not able to be cancelled, and also find
> the best way to cancel each one (for example, a thread blocking on an fcntl
> F_SETLKW can be interrupted with a signal).
>
> I also wonder if the multi-purpose threads have too many locks. It looks
> like fridge has two separate mutexes.
>
> Typically, when I implement a producer/consumer queue from scratch, I
> protect the queue with the same mutex as is paired with the condition
> variable used to signal the worker thread(s). Cancelling the thread can
> either be accomplished with a separate "cancel" flag (also protected by the
> mutex) or a special work item (perhaps put at the head of the queue instead
> of the tail, depending on if you want to drain the queue before shutdown or
> not).
>
> Any major changes here are 2.5 items, but it's worth starting a discussion.
>
> Frank
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> --
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>


--
___
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]: Fix mtime handling in FSAL_CEPH layoutcommit

2016-09-14 Thread GerritHub 
>From :

jlay...@redhat.com has uploaded a new change for review.

  https://review.gerrithub.io/294565

Change subject: Fix mtime handling in FSAL_CEPH layoutcommit
..

Fix mtime handling in FSAL_CEPH layoutcommit

This code only seems to care about the seconds field, but any difference
may only be visible in the nsec field. This means we need to switch to
clock_gettime() instead of time() as well.

Change-Id: Ib8df7085cc5b50463a1674cdf6e8ab8c9d64f97b
Signed-off-by: Jeff Layton 
---
M src/FSAL/FSAL_CEPH/mds.c
1 file changed, 10 insertions(+), 4 deletions(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib8df7085cc5b50463a1674cdf6e8ab8c9d64f97b
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: jlay...@redhat.com

--
___
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]: Check for NULL fullpath pointer in clean_export_paths

2016-09-14 Thread GerritHub 
>From :

jlay...@redhat.com has uploaded a new change for review.

  https://review.gerrithub.io/294564

Change subject: Check for NULL fullpath pointer in clean_export_paths
..

Check for NULL fullpath pointer in clean_export_paths

fullpath can be NULL here, in which case we'll end up with a null
pointer dereference. Check for that and treat it the same as an
empty path.

Change-Id: I5313728efde03cf6e090ad3462a6a2194ac6814f
Signed-off-by: Jeff Layton 
---
M src/support/exports.c
1 file changed, 1 insertion(+), 1 deletion(-)


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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I5313728efde03cf6e090ad3462a6a2194ac6814f
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: jlay...@redhat.com

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Threading models and the thread fridge

2016-09-14 Thread Frank Filz 
While looking at adding a thread to handle NLM blocked lock polling on FSALs
that don't support async blocking locks, I noticed there's a lot of
complexity in the thread fridge and a lot of different users each with their
own pool (some pools with only 1 thread).

I think it might be worth examining how we use the thread fridge and look
for ways to simplify it, and also make sure we are making the best use of
threads.

We have a number of uses of a "worker thread" model where a pool of threads
looks on a queue for work to do. One question is if every one of these uses
needs its own queue. The nfs_worker_thread threads probably do benefit from
being their own pool and queue, but do all the other uses.

Then there are some threads that wake up periodically to do work that is not
exactly queued (the reaper thread for example). It's not clear if these
threads avoid any wakeup at all If there is not any work to be done.

Then there are some threads that live to sit blocked on some system call to
wait for work to do. These threads particularly don't make sense to be in a
thread pool unless they block intermittently (for example the proposed
threads to actually block on locks). For shutdown purposes, we need to
examine if any of these threads is not able to be cancelled, and also find
the best way to cancel each one (for example, a thread blocking on an fcntl
F_SETLKW can be interrupted with a signal).

I also wonder if the multi-purpose threads have too many locks. It looks
like fridge has two separate mutexes.

Typically, when I implement a producer/consumer queue from scratch, I
protect the queue with the same mutex as is paired with the condition
variable used to signal the worker thread(s). Cancelling the thread can
either be accomplished with a separate "cancel" flag (also protected by the
mutex) or a special work item (perhaps put at the head of the queue instead
of the tail, depending on if you want to drain the queue before shutdown or
not).

Any major changes here are 2.5 items, but it's worth starting a discussion.

Frank


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


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel