[nfs-discuss] a draft for nfs v3 client provider proposal

[Danhua Shao]

For the provider, I will name it "nfsv3client".

For the conninfo_t, it is really a little bit difficult to get it. At 
NFS layer,  the connection has not been setup at the entry probe point 
and the connection has lost (conceptually) at the return probe point.  
Accord to my understanding to nfs source code, in rfscall(), both the 
"ci_remote" and "ci_protocol"can be obtained from a server info data 
structure: mi->mi_curr_serv.  For the "ci_local", I have not get an idea.

typedef struct conninfo {
string ci_local;/* local host address */
string ci_remote;   /* remote host address */
string ci_protocol; /* protocol (ipv4, ipv6, etc) */
} conninfo_t;

The reason is this data structure is very natural in server side where 
function calls happen from lower layer (RPC) to upper layer (like NFS).  
When the service functions are called at server side, the connection is 
still ok. But on the client side, function calls happen from upper layer 
(like NFS) to lower layer (RPC). This is also the reason why I prefer 
put probes at rfscall(), rather than nfs3_*() functions.

Regards,

Danhua

Adam Leventhal wrote:
> Hi Danhua,
>
> This looks very good. I have just a couple of questions/suggestions.
>
> The DTrace team had discussed having client-type providers of this and other
> protocols end with something a bit more verbose to make the distinction clear.
> Would you consider renaming the provider to something like nfsv3client?
>
> Was it difficult to provide the conninfo_t information in the entry probe?
> We've found that that can be the case in some situations for similar 
> providers.
>
> Please also submit this proposal to the DTrace community at
> dtrace-discuss at opensolaris.org when you're ready.
>
> Thanks.
>
> Adam
>
> On Tue, Sep 09, 2008 at 11:08:43AM -0500, Danhua Shao wrote:
>   
>> Hi,
>>
>> The attachment is the proposal of NFS v3 client provider. The last section, 
>> implementation, usually should not be part of a proposal because it is 
>> implementation related. I put it here because I want to have the feedback 
>> about my design.
>>
>> Welcome reviews!
>>
>> Regards,
>>
>> Danhua
>>
>>
>> 
>
>   
>> nfsv3c prvoider 
>>
>> Provider
>>
>> The nfsv3c provider provides probes for tracing NFS version 3 client 
>> activities, mainly the RPC requests to NFS server and RPC replies from NFS 
>> server. These probes are corresponding to the probes in nfsv3 provider which 
>> targets on NFS version 3 server activities. 
>>
>> Arguments
>>
>> In general, probe arguments are similar with those in nfsv3 provider.
>>
>> All NFS operation probes have the first argument in common:
>>
>>  args[0] conninfo_t *socket connection information
>>
>> The conninfo_t ructure is already used by the iSCSI target provider (iscsi) 
>> and the NFS v4 provider (nfsv4), and is intended for use by all provider 
>> which are providing some higher level protocol (e.g. iscsi, nfs, http, ftp).
>>
>>  typedef ruct conninfo {
>>  ring ci_local;/* local host address */
>>  ring ci_remote;   /* remote host address */
>>  ring ci_protocol; /* protocol (ipv4, ipv6, etc) */
>>  } conninfo_t;
>>
>> Operation probes have their second argument in common:
>>
>>  args[1] nfsv3opinfo_t * NFS v3 operation properties
>>
>>  typedef ruct nfsv3opinfo {
>>  ring noi_curpath;   /* current file handle path (if any) */
>>  cred_t *noi_cred;   /* credentials */
>>  uint64_t noi_xid;   /* transaction ID. It is undefiened in 
>> "nfsv3c:::op-*-request" probes because RPC has not been done when the 
>> request probes fired*/
>>  } nfsv3opinfo_t;
>>
>> Probes
>>
>> Below is a list of the probes along with the specific argument for each 
>> whose type is defined by the NFS v3 specification:
>>
>> probe name   args[2]
>>
>> nfsv3c:::op-access-request   ACCESS3args *
>> nfsv3c:::op-access-reply ACCESS3res *
>> nfsv3c:::op-commit-request   COMMIT3args *
>> nfsv3c:::op-commit-reply COMMIT3res *
>> nfsv3c:::op-create-request   CREATE3args *
>> nfsv3c:::op-create-reply CREATE3res *
>> nfsv3c:::op-fsinfo-request   FSINFO3args *
>> nfsv3c:::op-fsinfo-reply FSINFO3res *
>> nfsv3c:::op-fsat-request FSSTAT3args *
>> nfsv3c:::op-fsat-reply   FSSTAT3res *
>> nfsv3c:::op-getattr-request  GETATTR3args *
>> nfsv3c:::op-getattr-replyGETATTR3res *
>> nfsv3c:::op-lookup-request   LOOKUP3args *
>> nfsv3c:::op-lookup-reply LOOKUP3res *
>> nfsv3c:::op-link-request LINK3args *
>> nfsv3c:::op-link-reply   LINK3res *
>> nfsv3c:::op-mkdir-requestMKDIR3args *
>> nfsv3c:::op-mkdir-reply  MKDIR3res *
>> nfsv3c:::op-mknod-requestMKNOD3args *
>> nfsv3c:::op-mknod-reply  MKNOD3res *
>> nfsv3c:::op-null-request -
>> nfsv3c:::op-null-reply   -
>> nfsv3c:::op-pathconf-request PAT

[nfs-discuss] a draft for nfs v3 client provider proposal

[Adam Leventhal]

Hi Danhua,

This looks very good. I have just a couple of questions/suggestions.

The DTrace team had discussed having client-type providers of this and other
protocols end with something a bit more verbose to make the distinction clear.
Would you consider renaming the provider to something like nfsv3client?

Was it difficult to provide the conninfo_t information in the entry probe?
We've found that that can be the case in some situations for similar providers.

Please also submit this proposal to the DTrace community at
dtrace-discuss at opensolaris.org when you're ready.

Thanks.

Adam

On Tue, Sep 09, 2008 at 11:08:43AM -0500, Danhua Shao wrote:
> Hi,
>
> The attachment is the proposal of NFS v3 client provider. The last section, 
> implementation, usually should not be part of a proposal because it is 
> implementation related. I put it here because I want to have the feedback 
> about my design.
>
> Welcome reviews!
>
> Regards,
>
> Danhua
>
>

> nfsv3c prvoider 
> 
> Provider
> 
> The nfsv3c provider provides probes for tracing NFS version 3 client 
> activities, mainly the RPC requests to NFS server and RPC replies from NFS 
> server. These probes are corresponding to the probes in nfsv3 provider which 
> targets on NFS version 3 server activities. 
> 
> Arguments
> 
> In general, probe arguments are similar with those in nfsv3 provider.
> 
> All NFS operation probes have the first argument in common:
> 
>   args[0] conninfo_t *socket connection information
> 
> The conninfo_t ructure is already used by the iSCSI target provider (iscsi) 
> and the NFS v4 provider (nfsv4), and is intended for use by all provider 
> which are providing some higher level protocol (e.g. iscsi, nfs, http, ftp).
> 
>   typedef ruct conninfo {
>   ring ci_local;/* local host address */
>   ring ci_remote;   /* remote host address */
>   ring ci_protocol; /* protocol (ipv4, ipv6, etc) */
>   } conninfo_t;
> 
> Operation probes have their second argument in common:
> 
>   args[1] nfsv3opinfo_t * NFS v3 operation properties
> 
>   typedef ruct nfsv3opinfo {
>   ring noi_curpath;   /* current file handle path (if any) */
>   cred_t *noi_cred;   /* credentials */
>   uint64_t noi_xid;   /* transaction ID. It is undefiened in 
> "nfsv3c:::op-*-request" probes because RPC has not been done when the request 
> probes fired*/
>   } nfsv3opinfo_t;
> 
> Probes
> 
> Below is a list of the probes along with the specific argument for each whose 
> type is defined by the NFS v3 specification:
> 
> probe nameargs[2]
> 
> nfsv3c:::op-access-requestACCESS3args *
> nfsv3c:::op-access-reply  ACCESS3res *
> nfsv3c:::op-commit-requestCOMMIT3args *
> nfsv3c:::op-commit-reply  COMMIT3res *
> nfsv3c:::op-create-requestCREATE3args *
> nfsv3c:::op-create-reply  CREATE3res *
> nfsv3c:::op-fsinfo-requestFSINFO3args *
> nfsv3c:::op-fsinfo-reply  FSINFO3res *
> nfsv3c:::op-fsat-request  FSSTAT3args *
> nfsv3c:::op-fsat-replyFSSTAT3res *
> nfsv3c:::op-getattr-request   GETATTR3args *
> nfsv3c:::op-getattr-reply GETATTR3res *
> nfsv3c:::op-lookup-requestLOOKUP3args *
> nfsv3c:::op-lookup-reply  LOOKUP3res *
> nfsv3c:::op-link-request  LINK3args *
> nfsv3c:::op-link-replyLINK3res *
> nfsv3c:::op-mkdir-request MKDIR3args *
> nfsv3c:::op-mkdir-reply   MKDIR3res *
> nfsv3c:::op-mknod-request MKNOD3args *
> nfsv3c:::op-mknod-reply   MKNOD3res *
> nfsv3c:::op-null-request  -
> nfsv3c:::op-null-reply-
> nfsv3c:::op-pathconf-request  PATHCONF3args *
> nfsv3c:::op-pathconf-replyPATHCONF3res *
> nfsv3c:::op-read-request  READ3args *
> nfsv3c:::op-read-replyREAD3res *
> nfsv3c:::op-readdir-request   READDIR3args *
> nfsv3c:::op-readdir-reply READDIR3res *
> nfsv3c:::op-readdirplus-request   READDIRPLUS3args *
> nfsv3c:::op-readdirplus-reply READDIRPLUS3res *
> nfsv3c:::op-readlink-request  READLINK3args *
> nfsv3c:::op-readlink-replyREADLINK3res *
> nfsv3c:::op-remove-requestREMOVE3args *
> nfsv3c:::op-remove-reply  REMOVE3res *
> nfsv3c:::op-rename-requestRENAME3args *
> nfsv3c:::op-rename-reply  RENAME3res *
> nfsv3c:::op-rmdir-request RMDIR3args *
> nfsv3c:::op-rmdir-reply   RMDIR3res *
> nfsv3c:::op-setattr-request   SETATTR3args *
> nfsv3c:::op-setattr-reply SETATTR3res *
> nfsv3c:::op-symlink-request   SYMLINK3args *
> nfsv3c:::op-symlink-reply SYMLINK3res *
> nfsv3c:::op-write-request WRITE3args *
> nfsv3c:::op-write-reply   WRITE3res *
> 
> Note that op-null-* probes have an undefined args[2].
> 
> Implementation
> 
> In general, NFS client operations are implemented by function calls from VOP 
> operations to RPC calls: nfs3_*() -> rfs3call() -> rfscall() -> CLNT_CALL(). 
> Below 

[nfs-discuss] a draft for nfs v3 client provider proposal

[Danhua Shao]

Hi,

The attachment is the proposal of NFS v3 client provider. The last 
section, implementation, usually should not be part of a proposal 
because it is implementation related. I put it here because I want to 
have the feedback about my design.

Welcome reviews!

Regards,

Danhua


-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: proposal-nfsv3c.txt
URL: