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