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-reply     GETATTR3res *
> nfsv3c:::op-lookup-request    LOOKUP3args *
> nfsv3c:::op-lookup-reply      LOOKUP3res *
> nfsv3c:::op-link-request      LINK3args *
> nfsv3c:::op-link-reply                LINK3res *
> 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-reply    PATHCONF3res *
> nfsv3c:::op-read-request      READ3args *
> nfsv3c:::op-read-reply                READ3res *
> 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-reply    READLINK3res *
> nfsv3c:::op-remove-request    REMOVE3args *
> nfsv3c:::op-remove-reply      REMOVE3res *
> nfsv3c:::op-rename-request    RENAME3args *
> 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 CLNT_CALL are the network protocol specific implementations of RPC 
> (tcp, upd, rdma).  
> 
> NFS v3 client probes will be in rfscall() function, right before and after 
> call to CLNT_CALL(). The advantage is that XID becomes avaliable in rfscall() 
> and XID is the key to match operationts between NFS client and NFS server. 
> NFS client operations can be decoded from the second parameter of CLNT_CALL 
> and the arguments required by nfsv3c probes can also be obtained from other 
> parameters, directly or indirectly. 
> 
> 
> 

> _______________________________________________
> nfs-discuss mailing list
> nfs-discuss at opensolaris.org


-- 
Adam Leventhal, Fishworks                     http://blogs.sun.com/ahl

Reply via email to