[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: RGW: pass V3 flag to rgw_write() when !state

2017-10-17 Thread GerritHub 
>From Matt Benjamin :

Matt Benjamin has uploaded this change for review. ( 
https://review.gerrithub.io/382883


Change subject: RGW: pass V3 flag to rgw_write() when !state
..

RGW: pass V3 flag to rgw_write() when !state

Needed to permit librgw to simulate opens for NFSv3.

Change-Id: Ia7ba289a5941bd2f68c3ed678a95b9d16cb4fad0
Signed-off-by: Matt Benjamin 
---
M src/FSAL/FSAL_RGW/handle.c
1 file changed, 1 insertion(+), 1 deletion(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ia7ba289a5941bd2f68c3ed678a95b9d16cb4fad0
Gerrit-Change-Number: 382883
Gerrit-PatchSet: 1
Gerrit-Owner: Matt Benjamin 
--
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] NLM locks recovery issue

2017-10-17 Thread Frank Filz 
In HA environments the SM_NOTIFY has to be sent from the correct server 
address. For Ganesha, many of the HA functions are managed by scripts outside 
Ganesha, and SM_NOTIFY has to be part of that.



You are right that in a single server environment, that it would be convenient 
for Ganesha to send the SM_NOTIFY.



Frank



From: sriram patil [mailto:spsrirampa...@gmail.com]
Sent: Tuesday, October 17, 2017 9:46 AM
To: Frank Filz 
Cc: Malahal Naineni ; nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] NLM locks recovery issue



One more doubt on this, because I am still not sure why ganesha cannot call 
SM_NOTIFY, the way it calls SM_MON, SM_UNMON, etc.



Why can't we bump up the state number and call SM_NOTIFY (or just call 
SM_SIMU_CRASH which is combination of the two ops) on local rpc.statd every 
time we start ganesha? This will ask statd to send notify messages to all the 
clients explicitly. If the monitored client list is empty (first start), no 
notifications will be sent. If there are any clients in the list, they will be 
notified. If the client does not have server in the monitored list or the lock 
is not in the client cache, the notify signal will be ignored, otherwise it 
will try to reclaim the lock.



- Sriram



On Tue, Oct 17, 2017 at 9:59 PM, sriram patil  > wrote:

Ohh okay. Thanks for the help Frank and Malahal. I will look into this further. 
I will update on this once I get everything working.



- Sriram



On Tue, Oct 17, 2017 at 7:22 PM, Frank Filz  > wrote:

Yes, good point. That SHOULD all be covered by the scripting. To be honest, I 
haven’t actually looked at the various sample scripts, for development, I run a 
modified init.d script from the Ganesha 1.5 timeframe…



I think sm-notify –f does update the NSM state number.



Frank



From: sriram patil [mailto:spsrirampa...@gmail.com 
 ]
Sent: Monday, October 16, 2017 11:02 PM
To: Frank Filz  >
Cc: Malahal Naineni  >; 
nfs-ganesha-devel@lists.sourceforge.net 



Subject: Re: [Nfs-ganesha-devel] NLM locks recovery issue



Even with this, unless we can change the rpc.statd state, the SM_NOTIFY will 
not trigger any lock reclaims on the client side. I know the state number 
should be even/odd depending on whether the server is down/up. Is it safe to 
change the state number manually and then run sm_notify.ganesha? How can one 
guarantee the NSM/NLM semantics in case of server crash in the current scenario?



On Tue, Oct 17, 2017 at 12:37 AM, Frank Filz  > wrote:

The model of rpc.statd is that the client talks to its rpc.statd and the server 
talks to its rpc.statd, and the two rpc.statd talk to each other… So the 
sm_notify utility is used outside Ganesha essentially as part of rpc.statd to 
send the SM_NOTIFY requests. Theoretically, the server host should send 
SM_NOTIFY on reboot, of course since Ganesha is user space, it can crash 
without a server reboot.



There has been some discussion about pulling rpc.statd into Ganesha which would 
have some advantages and then it would make sense for Ganesha to issue the 
SM_NOTIFY.



Note that sm_notify queries a directory created and managed by rpc.statd. 
Ganesha does not manage the directory that persists the NLM client information.



Frank



From: sriram patil [mailto:spsrirampa...@gmail.com 
 ]
Sent: Monday, October 16, 2017 11:32 AM
To: Malahal Naineni  >
Cc: nfs-ganesha-devel@lists.sourceforge.net 

Subject: Re: [Nfs-ganesha-devel] NLM locks recovery issue



Hi,



I had a follow up question on this. I was looking into NSM related 
implementation as well. I see that ganesha handles the notify messages from 
clients and releases all the locks. But, when the server crashes/restarts it 
does not explicitly notify clients. I did not find any code sending SM_NOTIFY.



There is a separate binary, sm_notify.ganesha, but I am not sure why is it a 
separate binary instead of making a clnt_call with SM_NOTIFY.



There are respectives functions in nsm.h for every NSM proc, but nsm_notify is 
not implemented.



Is this handled in some other way? Are the service scripts supposed to use 
sm_notify.fanesha binary in some way or it is just test code?



Thanks,

Sriram



On 16-Oct-2017 11:55 PM, "sriram patil"  > wrote:





On 16-Oct-2017 12:50 PM, "Malahal Naineni"  > wrote:

NFSv3 protocol doesn't deal with locks, so there is no

Re: [Nfs-ganesha-devel] NLM locks recovery issue

2017-10-17 Thread sriram patil 
One more doubt on this, because I am still not sure why ganesha cannot call
SM_NOTIFY, the way it calls SM_MON, SM_UNMON, etc.

Why can't we bump up the state number and call SM_NOTIFY (or just call
SM_SIMU_CRASH which is combination of the two ops) on local rpc.statd every
time we start ganesha? This will ask statd to send notify messages to all
the clients explicitly. If the monitored client list is empty (first
start), no notifications will be sent. If there are any clients in the
list, they will be notified. If the client does not have server in the
monitored list or the lock is not in the client cache, the notify signal
will be ignored, otherwise it will try to reclaim the lock.

- Sriram

On Tue, Oct 17, 2017 at 9:59 PM, sriram patil 
wrote:

> Ohh okay. Thanks for the help Frank and Malahal. I will look into this
> further. I will update on this once I get everything working.
>
> - Sriram
>
> On Tue, Oct 17, 2017 at 7:22 PM, Frank Filz 
> wrote:
>
>> Yes, good point. That SHOULD all be covered by the scripting. To be
>> honest, I haven’t actually looked at the various sample scripts, for
>> development, I run a modified init.d script from the Ganesha 1.5 timeframe…
>>
>>
>>
>> I think sm-notify –f does update the NSM state number.
>>
>>
>>
>> Frank
>>
>>
>>
>> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
>> *Sent:* Monday, October 16, 2017 11:02 PM
>> *To:* Frank Filz 
>> *Cc:* Malahal Naineni ; nfs-ganesha-devel@lists.source
>> forge.net
>>
>> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>>
>>
>>
>> Even with this, unless we can change the rpc.statd state, the SM_NOTIFY
>> will not trigger any lock reclaims on the client side. I know the state
>> number should be even/odd depending on whether the server is down/up. Is it
>> safe to change the state number manually and then run sm_notify.ganesha?
>> How can one guarantee the NSM/NLM semantics in case of server crash in the
>> current scenario?
>>
>>
>>
>> On Tue, Oct 17, 2017 at 12:37 AM, Frank Filz 
>> wrote:
>>
>> The model of rpc.statd is that the client talks to its rpc.statd and the
>> server talks to its rpc.statd, and the two rpc.statd talk to each other… So
>> the sm_notify utility is used outside Ganesha essentially as part of
>> rpc.statd to send the SM_NOTIFY requests. Theoretically, the server host
>> should send SM_NOTIFY on reboot, of course since Ganesha is user space, it
>> can crash without a server reboot.
>>
>>
>>
>> There has been some discussion about pulling rpc.statd into Ganesha which
>> would have some advantages and then it would make sense for Ganesha to
>> issue the SM_NOTIFY.
>>
>>
>>
>> Note that sm_notify queries a directory created and managed by rpc.statd.
>> Ganesha does not manage the directory that persists the NLM client
>> information.
>>
>>
>>
>> Frank
>>
>>
>>
>> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
>> *Sent:* Monday, October 16, 2017 11:32 AM
>> *To:* Malahal Naineni 
>> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
>> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>>
>>
>>
>> Hi,
>>
>>
>>
>> I had a follow up question on this. I was looking into NSM related
>> implementation as well. I see that ganesha handles the notify messages from
>> clients and releases all the locks. But, when the server crashes/restarts
>> it does not explicitly notify clients. I did not find any code sending
>> SM_NOTIFY.
>>
>>
>>
>> There is a separate binary, sm_notify.ganesha, but I am not sure why is
>> it a separate binary instead of making a clnt_call with SM_NOTIFY.
>>
>>
>>
>> There are respectives functions in nsm.h for every NSM proc, but
>> nsm_notify is not implemented.
>>
>>
>>
>> Is this handled in some other way? Are the service scripts supposed to
>> use sm_notify.fanesha binary in some way or it is just test code?
>>
>>
>>
>> Thanks,
>>
>> Sriram
>>
>>
>>
>> On 16-Oct-2017 11:55 PM, "sriram patil"  wrote:
>>
>>
>>
>>
>>
>> On 16-Oct-2017 12:50 PM, "Malahal Naineni"  wrote:
>>
>> NFSv3 protocol doesn't deal with locks, so there is no mention of grace
>> period. NLM protocol is used in NFSv3 environments, so grace period does
>> exist in NLM.
>>
>>
>>
>> >> So, NFSv3 only server will mostly run with "Graceless = true"
>>
>>
>>
>> The above is true if you run ganesha with NFSv3 and disable NLM. This is
>> not the usual case! We do run with NLM enabled, so we have grace period
>> defined even in our NFSv3 only environments.
>>
>>
>>
>> Okay. So, NFSv4 grace period is used for NLM in case of NFSv3. The
>> nlm_grace_tv confused me. Thanks for clarifying.
>>
>>
>>
>>
>>
>> >> So, nfs4_Lock should actually use the NLM server grace period
>>
>>
>>
>> You mean nlm4_Lock?  I don't see a separate NLM grace period in
>> ganesha. nlm_grace_tv seems to be just grace time (not period).  It should
>>

Re: [Nfs-ganesha-devel] NLM locks recovery issue

2017-10-17 Thread sriram patil 
Ohh okay. Thanks for the help Frank and Malahal. I will look into this
further. I will update on this once I get everything working.

- Sriram

On Tue, Oct 17, 2017 at 7:22 PM, Frank Filz  wrote:

> Yes, good point. That SHOULD all be covered by the scripting. To be
> honest, I haven’t actually looked at the various sample scripts, for
> development, I run a modified init.d script from the Ganesha 1.5 timeframe…
>
>
>
> I think sm-notify –f does update the NSM state number.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Monday, October 16, 2017 11:02 PM
> *To:* Frank Filz 
> *Cc:* Malahal Naineni ; nfs-ganesha-devel@lists.
> sourceforge.net
>
> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>
>
>
> Even with this, unless we can change the rpc.statd state, the SM_NOTIFY
> will not trigger any lock reclaims on the client side. I know the state
> number should be even/odd depending on whether the server is down/up. Is it
> safe to change the state number manually and then run sm_notify.ganesha?
> How can one guarantee the NSM/NLM semantics in case of server crash in the
> current scenario?
>
>
>
> On Tue, Oct 17, 2017 at 12:37 AM, Frank Filz 
> wrote:
>
> The model of rpc.statd is that the client talks to its rpc.statd and the
> server talks to its rpc.statd, and the two rpc.statd talk to each other… So
> the sm_notify utility is used outside Ganesha essentially as part of
> rpc.statd to send the SM_NOTIFY requests. Theoretically, the server host
> should send SM_NOTIFY on reboot, of course since Ganesha is user space, it
> can crash without a server reboot.
>
>
>
> There has been some discussion about pulling rpc.statd into Ganesha which
> would have some advantages and then it would make sense for Ganesha to
> issue the SM_NOTIFY.
>
>
>
> Note that sm_notify queries a directory created and managed by rpc.statd.
> Ganesha does not manage the directory that persists the NLM client
> information.
>
>
>
> Frank
>
>
>
> *From:* sriram patil [mailto:spsrirampa...@gmail.com]
> *Sent:* Monday, October 16, 2017 11:32 AM
> *To:* Malahal Naineni 
> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] NLM locks recovery issue
>
>
>
> Hi,
>
>
>
> I had a follow up question on this. I was looking into NSM related
> implementation as well. I see that ganesha handles the notify messages from
> clients and releases all the locks. But, when the server crashes/restarts
> it does not explicitly notify clients. I did not find any code sending
> SM_NOTIFY.
>
>
>
> There is a separate binary, sm_notify.ganesha, but I am not sure why is it
> a separate binary instead of making a clnt_call with SM_NOTIFY.
>
>
>
> There are respectives functions in nsm.h for every NSM proc, but
> nsm_notify is not implemented.
>
>
>
> Is this handled in some other way? Are the service scripts supposed to use
> sm_notify.fanesha binary in some way or it is just test code?
>
>
>
> Thanks,
>
> Sriram
>
>
>
> On 16-Oct-2017 11:55 PM, "sriram patil"  wrote:
>
>
>
>
>
> On 16-Oct-2017 12:50 PM, "Malahal Naineni"  wrote:
>
> NFSv3 protocol doesn't deal with locks, so there is no mention of grace
> period. NLM protocol is used in NFSv3 environments, so grace period does
> exist in NLM.
>
>
>
> >> So, NFSv3 only server will mostly run with "Graceless = true"
>
>
>
> The above is true if you run ganesha with NFSv3 and disable NLM. This is
> not the usual case! We do run with NLM enabled, so we have grace period
> defined even in our NFSv3 only environments.
>
>
>
> Okay. So, NFSv4 grace period is used for NLM in case of NFSv3. The
> nlm_grace_tv confused me. Thanks for clarifying.
>
>
>
>
>
> >> So, nfs4_Lock should actually use the NLM server grace period
>
>
>
> You mean nlm4_Lock?  I don't see a separate NLM grace period in
> ganesha. nlm_grace_tv seems to be just grace time (not period).  It should
> be removed as it is NOT used at all.
>
>
>
> True. Will send this patch.
>
>
>
>
>
> Regards, Malahal.
>
>
>
>
>
> On Mon, Oct 16, 2017 at 11:35 AM, sriram patil 
> wrote:
>
> Hi,
>
> I was looking into NLM locking code for NFSv3. According to NLM/NSM
> protocols specifications, when server restarts, the client should send
> nlm4_Lock request with "reclaim" flag set. This reclaim is honored
> only if "NLM server" is in grace period. However, this code in
> nlm4_Lock function actually looks if the NFS server is in grace
> period, instead of checking NLM server.
>
> Also, NLM is used in case of NFSv3 and NFSv3 specs do not define grace
> period. So, NFSv3 only server will mostly run with "Graceless = true"
> and the lock recovery will not work on server restarts.
>
> So, nfs4_Lock should actually use the NLM server grace period
> (nlm_grace_tv) for handling reclaims. Since NFSv4 does not use NLM at
>

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: mdcache: don't hold the attr_lock for write over the setattr...

2017-10-17 Thread GerritHub 
>From Jeff Layton :

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


Change subject: mdcache: don't hold the attr_lock for write over the setattr2 
call
..

mdcache: don't hold the attr_lock for write over the setattr2 call

This is problematic, as some FSALs (e.g. Ceph) can take quite some time
to do their work. During this, getattr activity is stuck, and that can
lead to some deadlock situations with delegation returns.

Do the setattr2 call without holding the mutex, and only take it to
update the cache.

Change-Id: I08e2e752357e76d77583bd22f15f8bd72d71f39e
Signed-off-by: Jeff Layton 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c
1 file changed, 3 insertions(+), 7 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I08e2e752357e76d77583bd22f15f8bd72d71f39e
Gerrit-Change-Number: 382846
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: nfsv4: remove sd_grant_time from delegation state

2017-10-17 Thread GerritHub 
>From Jeff Layton :

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


Change subject: nfsv4: remove sd_grant_time from delegation state
..

nfsv4: remove sd_grant_time from delegation state

Nothing ever looks at it.

Change-Id: I0d69af56784b6f743dfaed92a10a07529aa6d34f
Signed-off-by: Jeff Layton 
---
M src/SAL/state_deleg.c
M src/include/sal_data.h
2 files changed, 0 insertions(+), 2 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I0d69af56784b6f743dfaed92a10a07529aa6d34f
Gerrit-Change-Number: 382844
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: nfsv4: fetch minorversion before freeing deleg_ctx

2017-10-17 Thread GerritHub 
>From Jeff Layton :

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


Change subject: nfsv4: fetch minorversion before freeing deleg_ctx
..

nfsv4: fetch minorversion before freeing deleg_ctx

Avoid a use-after-free here, by fetching the minorversion early on and
using that to determine how to clean things up at the end.

Change-Id: I27a4156d356bc104af92cb94544148e57f3c829d
Signed-off-by: Jeff Layton 
---
M src/FSAL_UP/fsal_up_top.c
1 file changed, 2 insertions(+), 1 deletion(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I27a4156d356bc104af92cb94544148e57f3c829d
Gerrit-Change-Number: 382845
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: reaper: remove the in_grace variable from reaper_state

2017-10-17 Thread GerritHub 
>From Jeff Layton :

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


Change subject: reaper: remove the in_grace variable from reaper_state
..

reaper: remove the in_grace variable from reaper_state

It's always overwritten on entry into reaper_run. Just check
nfs_in_grace() as necessary. Reorder fields in reaper_run for fewer
holes too, while we're at it.

Finally, remove explicit initialization of reaper_state. It's not
necessary since global variables are always initialized to zero in C.

Change-Id: Ib028ca03388ea184de2442ba1bf30374c97a4a5d
Signed-off-by: Jeff Layton 
---
M src/MainNFSD/nfs_reaper_thread.c
1 file changed, 3 insertions(+), 10 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib028ca03388ea184de2442ba1bf30374c97a4a5d
Gerrit-Change-Number: 382843
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix parent handle in mdc_lookup

2017-10-17 Thread GerritHub 
>From Malahal :

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


Change subject: Fix parent handle in mdc_lookup
..

Fix parent handle in mdc_lookup

If mdc_lookup() is looking ".." and parent handle is not present, call
mdc_get_parent to fix the parent handle.

Change-Id: Id1c68b4c1b90ad31d3079bf245b0b743b762804b
Signed-off-by: Malahal Naineni 
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
1 file changed, 9 insertions(+), 1 deletion(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Id1c68b4c1b90ad31d3079bf245b0b743b762804b
Gerrit-Change-Number: 382831
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