Re: [Nfs-ganesha-devel] nfs_worker_thread never executed code section

2018-03-10 Thread Frank Filz 
> Looking at the reply code just above this, discovered never executed code
> section.  I'm surprised the compiler isn't giving a warning.
> 
> Checking the Lieb re-indent commit, there was a label handle_err.
> 
> I'll go ahead and remove it.  It merely seems to be old logging
> Just a head's up for somebody to remember a need for this code.

I looked at the patch that removed the handle_err label. I'm not sure why I 
didn't remove the rest of this code at that time, but obviously it is dead 
code. Thanks for spotting it.

Frank

> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1411)
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1412) /* 
> Finish any
> request not already deleted */
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1413) if 
> (dpq_status
> == DUPREQ_SUCCESS)
> 00c21a6878 (William Allen Simpson 2015-06-12 07:36:46 -0400 1414)
>   dpq_status = nfs_dupreq_finish(>r_u.req.svc, res_nfs);
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1415) goto 
> freeargs;
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1416)
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1417) /* 
> Reject the
> request for authentication reason (incompatible
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1418)  * file 
> handle)
> */
> 822fdbc104 (Frank S. Filz 2014-03-20 15:01:31 -0400 1419) if
> (isInfo(COMPONENT_DISPATCH) || isInfo(COMPONENT_EXPORT)) {
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1420) 
> char
> dumpfh[1024];
> 33be2e2c11 (Frank S. Filz 2015-05-19 18:41:15 -0400 1421)
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1422)
>   sprint_fhandle3(dumpfh, (nfs_fh3 *) arg_nfs);
> 822fdbc104 (Frank S. Filz 2014-03-20 15:01:31 -0400 1423)
>   LogInfo(COMPONENT_DISPATCH,
> 66a09b1375 (Frank S. Filz 2017-12-07 11:30:32 -0800 1424)
>   "%s Request from host %s V3 not allowed on this export, proc=%"
> 66a09b1375 (Frank S. Filz 2017-12-07 11:30:32 -0800 1425)
>   PRIu32 ", FH=%s",
> ba42f03b2c (Frank S. Filz 2014-05-19 14:23:01 -0400 1426)
>   progname, client_ip,
> eb51d7a97b (William Allen Simpson 2017-01-13 19:19:55 -0500 1427)
>   reqdata->r_u.req.svc.rq_msg.cb_proc, dumpfh);
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1428) }
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1429) auth_rc 
> =
> AUTH_FAILED;
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1430)
> 02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1431)  
> auth_failure:



--
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] zero-copy read

2018-03-10 Thread Matt Benjamin 
Marcus has code that prototypes using gss_iov from mit-krb5 1.1.12.  I
recall describing this to you in 2013.

On Sat, Mar 10, 2018 at 11:12 AM, William Allen Simpson
 wrote:
> On 3/10/18 10:24 AM, William Allen Simpson wrote:
>
> But as I delved deeper, I'll have to make GSS work on vector i-o, as
> it currently requires one big buffer input.  This will be awhile.
>



-- 

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

--
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] zero-copy read

2018-03-10 Thread William Allen Simpson 

On 3/10/18 10:24 AM, William Allen Simpson wrote:

Finally, and what I'll do this weekend, my attempt to edit
xdr_nfs23.c won't pass checkpatch commit, because all the headers
are still pre-1989 pre-ANSI K

Unfortunately, Red Hat Linux doesn't seem to have cproto built-in,
even though it's on the usual https://linux.die.net/man/1/cproto.


Found it, installed it, and it wouldn't work in our complex
everything is a sub-library source structure.  So I did it by regex.

But as I delved deeper, I'll have to make GSS work on vector i-o, as
it currently requires one big buffer input.  This will be awhile.

--
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]: (xdr_nfs23.c) ANSI function prototypes

2018-03-10 Thread GerritHub 
>From :

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


Change subject: (xdr_nfs23.c) ANSI function prototypes
..

(xdr_nfs23.c) ANSI function prototypes

Also remove unused register pointer definitions.

Change-Id: I57303da3157ce051a8b0d31fcad08fe4d29a600a
Signed-off-by: William Allen Simpson 
---
M src/Protocols/XDR/xdr_nfs23.c
M src/include/nfs23.h
2 files changed, 147 insertions(+), 1,358 deletions(-)



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

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I57303da3157ce051a8b0d31fcad08fe4d29a600a
Gerrit-Change-Number: 403408
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] Change in ffilz/nfs-ganesha[next]: (nfs_worker_thread) remove never executed logging

2018-03-10 Thread GerritHub 
>From :

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


Change subject: (nfs_worker_thread) remove never executed logging
..

(nfs_worker_thread) remove never executed logging

Change-Id: I5434de3aa748026e2fe62866bb59b38b5a51bcd5
Signed-off-by: William Allen Simpson 
---
M src/MainNFSD/nfs_worker_thread.c
1 file changed, 0 insertions(+), 14 deletions(-)



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

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

Re: [Nfs-ganesha-devel] zero-copy read

2018-03-10 Thread Matt Benjamin 
Hi Bill,

On Sat, Mar 10, 2018 at 10:24 AM, William Allen Simpson
 wrote:
> Now that DanG has a workable vector i-o for read and write, I'm
> trying again to make reading zero-copy.  Man-oh-man, do we have
> our work cut out for us
>
> It seems that currently we provide a buffer to read.  Then XDR
> makes a new object, puts headers into it, makes another data_val
> and copies data into that, then it is all eventually passed to
> ntirpc where a buffer is created and all copied into that.
>
> If GSS, another copy is made.  (This one cannot be avoided.)
>
> So we're copying large amounts of data 4-5 times.   Not counting
> whatever the FSAL library call does internally.

Sounds like you have lots to work on.

>
> Then there is NFS_LOOKAHEAD_READ, and a nfs_request_lookahead.
> Could somebody explain what that is doing?

These are just tracking the ops being decoded, currently to help
decide if reqs should be cached.  It copies no data.

>
> AFAICT, the only test is in dup_req, and it won't keep the dup_req
> "because large, though idempotent".  Isn't a large read exactly
> where we'd benefit from holding onto a dup_req?

Basically, no.  The purpose of the DRC is to identify requests that
change the state of files/objects (are non-idempotent), and to satisfy
a client's retry of such a request, without re-executing it.  The goal
is not to be a data cache.

>
> NFS_LOOKAHEAD_HIGH_LATENCY is never used.

It's a constant.

>
> There are a lot of XDR tests for x_public having the pointer to
> nfs_request_lookahead, yet setting that pointer is one of the
> early things in nfs_worker_thread.c nfs_rpc_process_request().

It sets the structure in x_public so that it can be accessed from
within XDR decoders.

>
> Finally, and what I'll do this weekend, my attempt to edit
> xdr_nfs23.c won't pass checkpatch commit, because all the headers
> are still pre-1989 pre-ANSI K
>
> Unfortunately, Red Hat Linux doesn't seem to have cproto built-in,
> even though it's on the usual https://linux.die.net/man/1/cproto.
>
> --
> 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



-- 

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

--
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] zero-copy read

2018-03-10 Thread William Allen Simpson 

Now that DanG has a workable vector i-o for read and write, I'm
trying again to make reading zero-copy.  Man-oh-man, do we have
our work cut out for us

It seems that currently we provide a buffer to read.  Then XDR
makes a new object, puts headers into it, makes another data_val
and copies data into that, then it is all eventually passed to
ntirpc where a buffer is created and all copied into that.

If GSS, another copy is made.  (This one cannot be avoided.)

So we're copying large amounts of data 4-5 times.   Not counting
whatever the FSAL library call does internally.

Then there is NFS_LOOKAHEAD_READ, and a nfs_request_lookahead.
Could somebody explain what that is doing?

AFAICT, the only test is in dup_req, and it won't keep the dup_req
"because large, though idempotent".  Isn't a large read exactly
where we'd benefit from holding onto a dup_req?

NFS_LOOKAHEAD_HIGH_LATENCY is never used.

There are a lot of XDR tests for x_public having the pointer to
nfs_request_lookahead, yet setting that pointer is one of the
early things in nfs_worker_thread.c nfs_rpc_process_request().

Finally, and what I'll do this weekend, my attempt to edit
xdr_nfs23.c won't pass checkpatch commit, because all the headers
are still pre-1989 pre-ANSI K

Unfortunately, Red Hat Linux doesn't seem to have cproto built-in,
even though it's on the usual https://linux.die.net/man/1/cproto.

--
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] About referrals in FSAL_VFS

2018-03-10 Thread Sriram Patil 
Okay, sounds good. Will work towards getting this right.

Thanks,
Sriram

From: Frank Filz 
Date: Friday, March 9, 2018 at 11:20 PM
To: Sriram Patil , 
"nfs-ganesha-devel@lists.sourceforge.net" 

Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hmm, did I sow confusion about fs_locations in attrlist? I think that would be 
the best solution. We do need to work to be careful about tracking the validity 
of different parts of the attrlist, since we don’t necessarily want to fetch 
the fs_locations from the filesystem every time we refresh attributes.

I think with fs_locations being in the attrlist, it becomes much easier to have 
a sub-fsal with different handling.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Friday, March 9, 2018 9:09 AM
To: Frank Filz ; 
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Hi Frank,

Now that the referral fixes for pynfs are approved (not merged yet), I wanted 
to work on the subfsal layer to extend this to subfsal and allow having 
referral points as desired. As we had discussed before, it would be a good idea 
to store fs locations in the attrlist, but a few days back on IRC you mentioned 
that we do not want to jump onto that as yet. So, I was thinking of supporting 
referrals and fs_locations at subfsal layer a little differently which will not 
involve a lot of changes.

Currently, the vfs_fsal_obj_handle stores fsroot and fslocations as part of 
directory (hdl->u.directory). I was thinking of moving these out of the union 
and make them first class variable in the structure or the union inside it. 
This way the fsroot and fslocations can be stored for any file type, for 
example a symlink. I will be adding some subfsal callbacks for populating and 
retrieving the fslocation details as discussed before.

Let me know if this looks like a good thing to do or should we think about 
fslocations in attrlist?

Thanks,
Sriram

From: Sriram Patil >
Date: Friday, February 9, 2018 at 10:30 AM
To: Frank Filz >, 
"nfs-ganesha-devel@lists.sourceforge.net"
 
>
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Okay, so there are a bunch of things that we need to do. I will just list them 
down here, let me know if I miss anything.

  1.  Fs locations can be moved to attrlist and FSAL can fill it as part of 
getattr if required
  2.  We need ref counting for fs locations for handling attr copy where 
multiple objects can hold reference to fs locations
  3.  Have a validity bit for fs locations. Allow a dbus command to invalidate 
all fs_locations to be able to refresh the locations for dynamic updates
  4.  Add methods/callbacks to subfsal mechanism to allow subfsals to choose 
how referrals work for them. This should also allow a way to follow the default 
VFS mechanism

Thanks,
Sriram

From: Frank Filz >
Date: Friday, February 9, 2018 at 12:05 AM
To: Sriram Patil >, 
"nfs-ganesha-devel@lists.sourceforge.net"
 
>
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

There are places the struct attrlist gets copied, if so, either the referral 
needs to be duplicated in that copy, or it needs to be a single entity with a 
refcount.

One advantage of adding the referral to the struct attrlist is that MDCACHE 
will manage cache life of it.

It may or may not be worth having a separate cache validity bit for it 
(advantage of doing that is then 9P and V3 GETATTR won’t need to fetch it. 
Also, conceivably we could have a dBUS trigger to invalidate all referral 
attributes (on the other hand, without a separate validity bit, that dBUS 
command could just invalidate the attributes of any object that had a non-empty 
referral, though that would delay when a fs_locations attribute becomes visible 
if added to an object that previously didn’t have one…) I think I just talked 
myself into a separate validity bit. We will want to be able to tell Ganesha to 
refresh fs_locations, it can march through all the cached inodes and invalidate 
the fs_locations attribute (whether it was empty or not) thus allowing 
dynamically moving a sub-tree.

Frank

From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Thursday, February 8, 2018 9:33 AM
To: Frank Filz >; 
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re:

[Nfs-ganesha-devel] nfs_worker_thread never executed code section

2018-03-10 Thread William Allen Simpson 

Looking at the reply code just above this, discovered never executed
code section.  I'm surprised the compiler isn't giving a warning.

Checking the Lieb re-indent commit, there was a label handle_err.

I'll go ahead and remove it.  It merely seems to be old logging
Just a head's up for somebody to remember a need for this code.

02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1411)
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1412)   /* 
Finish any request not already deleted */
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1413)   if 
(dpq_status == DUPREQ_SUCCESS)
00c21a6878 (William Allen Simpson 2015-06-12 07:36:46 -0400 1414)   
dpq_status = nfs_dupreq_finish(>r_u.req.svc, res_nfs);
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1415)   goto 
freeargs;
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1416)
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1417)   /* 
Reject the request for authentication reason (incompatible
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1418)* file 
handle) */
822fdbc104 (Frank S. Filz 2014-03-20 15:01:31 -0400 1419)   if 
(isInfo(COMPONENT_DISPATCH) || isInfo(COMPONENT_EXPORT)) {
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1420)   
char dumpfh[1024];
33be2e2c11 (Frank S. Filz 2015-05-19 18:41:15 -0400 1421)
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1422)   
sprint_fhandle3(dumpfh, (nfs_fh3 *) arg_nfs);
822fdbc104 (Frank S. Filz 2014-03-20 15:01:31 -0400 1423)   
LogInfo(COMPONENT_DISPATCH,
66a09b1375 (Frank S. Filz 2017-12-07 11:30:32 -0800 1424)   
"%s Request from host %s V3 not allowed on this export, proc=%"
66a09b1375 (Frank S. Filz 2017-12-07 11:30:32 -0800 1425)   
PRIu32 ", FH=%s",
ba42f03b2c (Frank S. Filz 2014-05-19 14:23:01 -0400 1426)   
progname, client_ip,
eb51d7a97b (William Allen Simpson 2017-01-13 19:19:55 -0500 1427)  
 reqdata->r_u.req.svc.rq_msg.cb_proc, dumpfh);
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1428)   }
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1429)   auth_rc 
= AUTH_FAILED;
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1430)
02526d7325 (Jim Lieb  2013-10-10 20:50:47 -0700 1431)  auth_failure:



--
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