Below is a proposal I''ve developed along with Sam Falkner and Lisa Week
for
a new DTrace provider for NFS v4. If you have comments, please voice them
by November 20 -- we hope to file the PSARC case shortly after that.
Thanks.
Adam
---8<---
NFS v4 Provider
All NFS operation probes have the first argument in common:
args[0] conninfo_t * socket connection information
The conninfo_t structure is already used by the iSCSI target provider (iscsi),
and is intended for use by all provider which are providing some higher
level protocol (e.g. iscsi, nfs, http, ftp).
typedef struct conninfo {
string ci_local; /* local host address */
string ci_remote; /* remote host address */
string ci_protocol; /* protocol (ipv4, ipv6, etc) */
} conninfo_t;
Operation probes have their second argument in comment:
args[1] nfsv4opinfo_t * NFS v4 operation properties
typedef struct nfsv4opinfo {
string noi_curpath; /* current file handle path (if any) */
cred_t *noi_cred; /* credentials */
uint64_t noi_xid; /* transaction ID */
} nfsv4opinfo_t;
Below is a list of the top level operation probes along with the specific
argument for each whose type is defined by the NFS v4 specification:
probe name args[2]
---------- -------
nfsv4:::compound-op-start COMPOUND4args *
nfsv4:::compound-op-done COMPOUND4res *
Below is a list of operation probes along with the specific argument
for each whose type is defined by the NFS v4 specification:
probe name args[2]
---------- -------
nfsv4:::op-access-start ACCESS4args *
nfsv4:::op-access-done ACCESS4res *
nfsv4:::op-close-start CLOSE4args *
nfsv4:::op-close-done CLOSE4res *
nfsv4:::op-commit-start COMMIT4args *
nfsv4:::op-commit-done COMMIT4res *
nfsv4:::op-create-start CREATE4args *
nfsv4:::op-create-done CREATE4res *
nfsv4:::op-delegpurge-start DELEGPURGE4args *
nfsv4:::op-delegpurge-done DELEGPURGE4res *
nfsv4:::op-delegreturn-start DELEGRETURN4args *
nfsv4:::op-delegreturn-done DELEGRETURN4res *
nfsv4:::op-getattr-start GETATTR4args *
nfsv4:::op-getattr-done GETATTR4res *
nfsv4:::op-getfh-start GETFH4args *
nfsv4:::op-getfh-done GETFH4res *
nfsv4:::op-link-start LINK4args *
nfsv4:::op-link-done LINK4res *
nfsv4:::op-lock-start LOCK4args *
nfsv4:::op-lock-done LOCK4res *
nfsv4:::op-lockt-start LOCKT4args *
nfsv4:::op-lockt-done LOCKT4res *
nfsv4:::op-locku-start LOCKU4args *
nfsv4:::op-locku-done LOCKU4res *
nfsv4:::op-lookup-start LOOKUP4args *
nfsv4:::op-lookup-done LOOKUP4res *
nfsv4:::op-lookupp-start LOOKUPP4args *
nfsv4:::op-lookupp-done LOOKUPP4res *
nfsv4:::op-nverify-start NVERIFY4args *
nfsv4:::op-nverify-done NVERIFY4res *
nfsv4:::op-open-start OPEN4args *
nfsv4:::op-open-done OPEN4res *
nfsv4:::op-open-confirm-start OPEN_CONFIRM4args *
nfsv4:::op-open-confirm-done OPEN_CONFIRM4res *
nfsv4:::op-open-downgrade-start OPEN_DOWNGRADE4args *
nfsv4:::op-open-downgrade-done OPEN_DOWNGRADE4res *
nfsv4:::op-openattr-start OPENATTR4args *
nfsv4:::op-openattr-done OPENATTR4res *
nfsv4:::op-putfh-start PUTFH4args *
nfsv4:::op-putfh-done PUTFH4res *
nfsv4:::op-putpubfh-start PUTPUBFH4args *
nfsv4:::op-putpubfh-done PUTPUBFH4res *
nfsv4:::op-putrootfh-start PUTROOTFH4args *
nfsv4:::op-putrootfh-done PUTROOTFH4res *
nfsv4:::op-read-start READ4args *
nfsv4:::op-read-done READ4res *
nfsv4:::op-readlink-start READLINK4args *
nfsv4:::op-readlink-done READLINK4res *
nfsv4:::op-release-lockowner-start RELEASE_LOCKOWNER4args *
nfsv4:::op-release-lockowner-done RELEASE_LOCKOWNER4res *
nfsv4:::op-remove-start REMOVE4args *
nfsv4:::op-remove-done REMOVE4res *
nfsv4:::op-rename-start RENAME4args *
nfsv4:::op-rename-done RENAME4res *
nfsv4:::op-renew-start RENEW4args *
nfsv4:::op-renew-done RENEW4res *
nfsv4:::op-restorefh-start <none>
nfsv4:::op-restorefh-done <none>
nfsv4:::op-savefh-start SAVEFH4args *
nfsv4:::op-savefh-done SAVEFH4res *
nfsv4:::op-secinfo-start SECINFO4args *
nfsv4:::op-secinfo-done SECINFO4res *
nfsv4:::op-setattr-start SETATTR4args *
nfsv4:::op-setattr-done SETATTR4res *
nfsv4:::op-setclientid-start SETCLIENTID4args *
nfsv4:::op-setclientid-done SETCLIENTID4res *
nfsv4:::op-setclientid-confirm-start SETCLIENTID_CONFIRM4args *
nfsv4:::op-setclientid-confirm-done SETCLIENTID_CONFIRM4res *
nfsv4:::op-verify-start VERIFY4args *
nfsv4:::op-verify-done VERIFY4res *
nfsv4:::op-write-start WRITE4args *
nfsv4:::op-write-done WRITE4res *
Callback probes have an undefined second argument; this slot is reserved for
future use.
Below is a list of the top level callback probes along with the specific
argument for each whose type is defined by the NFS v4 specification:
probe name args[2]
---------- -------
nfsv4:::compound-cb-start CB_COMPOUND4args *
nfsv4:::compound-cb-done CB_COMPOUND4res *
Below is a list of callback probes along with the specific argument
for each whose type is defined by the NFS v4 specification:
probe name args[2]
---------- -------
nfsv4:::cb-getattr-start CB_GETATTR4args *
nfsv4:::cb-getattr-done CB_GETATTR4res *
nfsv4:::cb-recall-start CB_RECALL4args *
nfsv4:::cb-recall-done CB_RECALL4res *
(Note that since the Solaris NFS v4 implementation does not yet use the
''getattr'' callback, the probe will not be implemented; it is
noted here in
anticipation of a future implementation).
--->8---
--
Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Thu, 2007-11-15 at 01:14 -0800, Adam Leventhal wrote:> The conninfo_t structure is already used by the iSCSI target provider (iscsi), > and is intended for use by all provider which are providing some higher > level protocol (e.g. iscsi, nfs, http, ftp). > > typedef struct conninfo { > string ci_local; /* local host address */ > string ci_remote; /* remote host address */ > string ci_protocol; /* protocol (ipv4, ipv6, etc) */ > } conninfo_t;For structures like this which exist only in "D" code and not in C, is it feasible to add additional fields later?
Note that the READDIR operation is missing from the list below. Given that these protocol mechanisms will exist at client and server, it would be helpful to have a naming mechanism that differentiated this fact. I also assume that when NFSv4.1 is introduced that the provider will be expanded to something like: nfsv41:::op-access-start ACCESS4args * ... Spencer On Nov 15, 2007, at 3:14 AM, Adam Leventhal wrote:> Below is a proposal I''ve developed along with Sam Falkner and Lisa > Week for > a new DTrace provider for NFS v4. If you have comments, please > voice them > by November 20 -- we hope to file the PSARC case shortly after that. > > Thanks. > > Adam > > ---8<--- > > NFS v4 Provider > > All NFS operation probes have the first argument in common: > > args[0] conninfo_t * socket connection information > > The conninfo_t structure is already used by the iSCSI target > provider (iscsi), > and is intended for use by all provider which are providing some > higher > level protocol (e.g. iscsi, nfs, http, ftp). > > typedef struct conninfo { > string ci_local; /* local host address */ > string ci_remote; /* remote host address */ > string ci_protocol; /* protocol (ipv4, ipv6, etc) */ > } conninfo_t; > > > Operation probes have their second argument in comment: > > args[1] nfsv4opinfo_t * NFS v4 operation properties > > typedef struct nfsv4opinfo { > string noi_curpath; /* current file handle path (if any) */ > cred_t *noi_cred; /* credentials */ > uint64_t noi_xid; /* transaction ID */ > } nfsv4opinfo_t; > > Below is a list of the top level operation probes along with the > specific > argument for each whose type is defined by the NFS v4 specification: > > probe name args[2] > ---------- ------- > nfsv4:::compound-op-start COMPOUND4args * > nfsv4:::compound-op-done COMPOUND4res * > > Below is a list of operation probes along with the specific argument > for each whose type is defined by the NFS v4 specification: > > probe name args[2] > ---------- ------- > nfsv4:::op-access-start ACCESS4args * > nfsv4:::op-access-done ACCESS4res * > nfsv4:::op-close-start CLOSE4args * > nfsv4:::op-close-done CLOSE4res * > nfsv4:::op-commit-start COMMIT4args * > nfsv4:::op-commit-done COMMIT4res * > nfsv4:::op-create-start CREATE4args * > nfsv4:::op-create-done CREATE4res * > nfsv4:::op-delegpurge-start DELEGPURGE4args * > nfsv4:::op-delegpurge-done DELEGPURGE4res * > nfsv4:::op-delegreturn-start DELEGRETURN4args * > nfsv4:::op-delegreturn-done DELEGRETURN4res * > nfsv4:::op-getattr-start GETATTR4args * > nfsv4:::op-getattr-done GETATTR4res * > nfsv4:::op-getfh-start GETFH4args * > nfsv4:::op-getfh-done GETFH4res * > nfsv4:::op-link-start LINK4args * > nfsv4:::op-link-done LINK4res * > nfsv4:::op-lock-start LOCK4args * > nfsv4:::op-lock-done LOCK4res * > nfsv4:::op-lockt-start LOCKT4args * > nfsv4:::op-lockt-done LOCKT4res * > nfsv4:::op-locku-start LOCKU4args * > nfsv4:::op-locku-done LOCKU4res * > nfsv4:::op-lookup-start LOOKUP4args * > nfsv4:::op-lookup-done LOOKUP4res * > nfsv4:::op-lookupp-start LOOKUPP4args * > nfsv4:::op-lookupp-done LOOKUPP4res * > nfsv4:::op-nverify-start NVERIFY4args * > nfsv4:::op-nverify-done NVERIFY4res * > nfsv4:::op-open-start OPEN4args * > nfsv4:::op-open-done OPEN4res * > nfsv4:::op-open-confirm-start OPEN_CONFIRM4args * > nfsv4:::op-open-confirm-done OPEN_CONFIRM4res * > nfsv4:::op-open-downgrade-start OPEN_DOWNGRADE4args * > nfsv4:::op-open-downgrade-done OPEN_DOWNGRADE4res * > nfsv4:::op-openattr-start OPENATTR4args * > nfsv4:::op-openattr-done OPENATTR4res * > nfsv4:::op-putfh-start PUTFH4args * > nfsv4:::op-putfh-done PUTFH4res * > nfsv4:::op-putpubfh-start PUTPUBFH4args * > nfsv4:::op-putpubfh-done PUTPUBFH4res * > nfsv4:::op-putrootfh-start PUTROOTFH4args * > nfsv4:::op-putrootfh-done PUTROOTFH4res * > nfsv4:::op-read-start READ4args * > nfsv4:::op-read-done READ4res * > nfsv4:::op-readlink-start READLINK4args * > nfsv4:::op-readlink-done READLINK4res * > nfsv4:::op-release-lockowner-start RELEASE_LOCKOWNER4args * > nfsv4:::op-release-lockowner-done RELEASE_LOCKOWNER4res * > nfsv4:::op-remove-start REMOVE4args * > nfsv4:::op-remove-done REMOVE4res * > nfsv4:::op-rename-start RENAME4args * > nfsv4:::op-rename-done RENAME4res * > nfsv4:::op-renew-start RENEW4args * > nfsv4:::op-renew-done RENEW4res * > nfsv4:::op-restorefh-start <none> > nfsv4:::op-restorefh-done <none> > nfsv4:::op-savefh-start SAVEFH4args * > nfsv4:::op-savefh-done SAVEFH4res * > nfsv4:::op-secinfo-start SECINFO4args * > nfsv4:::op-secinfo-done SECINFO4res * > nfsv4:::op-setattr-start SETATTR4args * > nfsv4:::op-setattr-done SETATTR4res * > nfsv4:::op-setclientid-start SETCLIENTID4args * > nfsv4:::op-setclientid-done SETCLIENTID4res * > nfsv4:::op-setclientid-confirm-start SETCLIENTID_CONFIRM4args * > nfsv4:::op-setclientid-confirm-done SETCLIENTID_CONFIRM4res * > nfsv4:::op-verify-start VERIFY4args * > nfsv4:::op-verify-done VERIFY4res * > nfsv4:::op-write-start WRITE4args * > nfsv4:::op-write-done WRITE4res * > > > Callback probes have an undefined second argument; this slot is > reserved for > future use. > > Below is a list of the top level callback probes along with the > specific > argument for each whose type is defined by the NFS v4 specification: > > probe name args[2] > ---------- ------- > nfsv4:::compound-cb-start CB_COMPOUND4args * > nfsv4:::compound-cb-done CB_COMPOUND4res * > > Below is a list of callback probes along with the specific argument > for each whose type is defined by the NFS v4 specification: > > probe name args[2] > ---------- ------- > nfsv4:::cb-getattr-start CB_GETATTR4args * > nfsv4:::cb-getattr-done CB_GETATTR4res * > nfsv4:::cb-recall-start CB_RECALL4args * > nfsv4:::cb-recall-done CB_RECALL4res * > > > (Note that since the Solaris NFS v4 implementation does not yet use > the > ''getattr'' callback, the probe will not be implemented; it is noted > here in > anticipation of a future implementation). > > --->8--- > > -- > Adam Leventhal, FishWorks http:// > blogs.sun.com/ahl > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
On Thu, Nov 15, 2007 at 03:03:15PM -0600, Spencer Shepler wrote:> Given that these protocol mechanisms will exist at client and > server, it would be helpful to have a naming mechanism that > differentiated this fact.Perhaps the module name could be used as the differentiator? nfsv4:client::op-<op> nfsv4:server::op-<op>> I also assume that when NFSv4.1 > is introduced that the provider will be expanded to something > like: > > nfsv41:::op-access-start ACCESS4args * > ...Does 4.1 differ so much from 4 that the provider name itself must differ?
On Nov 15, 2007, at 3:14 PM, Nicolas Williams wrote:> On Thu, Nov 15, 2007 at 03:03:15PM -0600, Spencer Shepler wrote: >> Given that these protocol mechanisms will exist at client and >> server, it would be helpful to have a naming mechanism that >> differentiated this fact. > > Perhaps the module name could be used as the differentiator? > > nfsv4:client::op-<op> > nfsv4:server::op-<op>No preference; just needs to be present. I will take the opportunity to note that there are certain optimizations (not drastic but they do exist) such that the argument/results structures of interest are extended in their local representation and in that vein may not be fully populated. There also may be future optimizations such that the NFSv4 operations are not "executed" separately but are grouped together under one stream of execution and therefore the dtrace points may not represent true operation processing. If the intent is to capture all of the processing of an operation under these dtrace points, then intent may be broken or hard to supply moving forward.> >> I also assume that when NFSv4.1 >> is introduced that the provider will be expanded to something >> like: >> >> nfsv41:::op-access-start ACCESS4args * >> ... > > Does 4.1 differ so much from 4 that the provider name itself must > differ?That''s funny. Yes. Spencer
> >>Given that these protocol mechanisms will exist at client and > >>server, it would be helpful to have a naming mechanism that > >>differentiated this fact. > > > >Perhaps the module name could be used as the differentiator? > > > >nfsv4:client::op-<op> > >nfsv4:server::op-<op> > > No preference; just needs to be present.The plan is to have a different provider; either nfsv4c or nfsv4client or something.> >> I also assume that when NFSv4.1 > >>is introduced that the provider will be expanded to something > >>like: > >> > >> nfsv41:::op-access-start ACCESS4args * > >> ... > > > >Does 4.1 differ so much from 4 that the provider name itself must > >differ? > > That''s funny. Yes.How funny is it? Will we want to support both the nfsv4 and nfsv41 providers? Will the probes overlap in a way that would create incompatibilities? Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
> Note that the READDIR operation is missing from the list below.Nice catch. We will, of course, have a probe for that operation. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Nov 15, 2007, at 4:27 PM, Adam Leventhal wrote:>>>> Given that these protocol mechanisms will exist at client and >>>> server, it would be helpful to have a naming mechanism that >>>> differentiated this fact. >>> >>> Perhaps the module name could be used as the differentiator? >>> >>> nfsv4:client::op-<op> >>> nfsv4:server::op-<op> >> >> No preference; just needs to be present. > > The plan is to have a different provider; either nfsv4c or > nfsv4client or > something.Great.> >>>> I also assume that when NFSv4.1 >>>> is introduced that the provider will be expanded to something >>>> like: >>>> >>>> nfsv41:::op-access-start ACCESS4args * >>>> ... >>> >>> Does 4.1 differ so much from 4 that the provider name itself must >>> differ? >> >> That''s funny. Yes. > > How funny is it? Will we want to support both the nfsv4 and nfsv41 > providers? > Will the probes overlap in a way that would create incompatibilities?Funny == flippant, in the sense that I would have expected Nico to know some of the details and was poking him a little on the issue (Hi, Nico). as for the details.. NFSv4.1 is introducing a set of new operations to inflict the new set of features within the protocol. There is a mix of optional and mandatory to implement operations and corresponding args/results. That isn''t going to be a problem. The real issues are that there are 4-5 operations that have been designated as mandatory-not-to-implement; meaning that they may appear as defined in the RPC language but are never to be used -- the vestiges of NFSv4.0. That isn''t too much of a problem either. The larger issue is that there are a couple of arguments (OPEN mainly) that have been extended through the NFSv4 minor version rules to include additional parameters in effect. This means that an NFSv4 and NFSv4.1 provider should not share the argument definition. I don''t see that as much of a problem either if the providers were per minor version (e.g. NFSv4.0 and NFSv4.1). In summary, the proposal is fine with me as long as we have an expectation that a new provider (similar in size and complexity) will be in place for NFSv4.1. Spencer
On Thu, Nov 15, 2007 at 06:43:07PM -0600, Spencer Shepler wrote:> NFSv4.1 is introducing a set of new operations to inflict the > new set of features within the protocol. There is a mix of > optional and mandatory to implement operations and corresponding > args/results. That isn''t going to be a problem. The real issues > are that there are 4-5 operations that have been designated > as mandatory-not-to-implement; meaning that they may appear > as defined in the RPC language but are never to be used -- > the vestiges of NFSv4.0. That isn''t too much of a problem either. > The larger issue is that there are a couple of arguments (OPEN mainly) > that have been extended through the NFSv4 minor version rules > to include additional parameters in effect. This means that > an NFSv4 and NFSv4.1 provider should not share the argument > definition. I don''t see that as much of a problem either if > the providers were per minor version (e.g. NFSv4.0 and NFSv4.1).Will an NFSv4.1 server be able to handle requests from a 4.0 client? Are you suggesting that there will be a probe called nfsv41:::op-open-start which has as its argument a OPEN41args structure? It wouldn''t be possible to create some parameter which included the relevant information from either minor version?> In summary, the proposal is fine with me as long as we have > an expectation that a new provider (similar in size > and complexity) will be in place for NFSv4.1.Yes, we''re hoping that projects groups will realize the utility of DTrace providers and implement them as a part of their project. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Thu, Nov 15, 2007 at 06:43:07PM -0600, Spencer Shepler wrote:> On Nov 15, 2007, at 4:27 PM, Adam Leventhal wrote: > >>> Does 4.1 differ so much from 4 that the provider name itself must > >>> differ? > >> > >> That''s funny. Yes. > > > > How funny is it? Will we want to support both the nfsv4 and nfsv41 > > providers? > > Will the probes overlap in a way that would create incompatibilities? > > Funny == flippant, in the sense that I would have expected Nico to > know some of > the details and was poking him a little on the issue (Hi, Nico).Yes, _I_ got it :)> [...] > The larger issue is that there are a couple of arguments (OPEN mainly) > that have been extended through the NFSv4 minor version rules > to include additional parameters in effect. This means that > an NFSv4 and NFSv4.1 provider should not share the argument > definition. I don''t see that as much of a problem either if > the providers were per minor version (e.g. NFSv4.0 and NFSv4.1).Certainly there''s no problem if we have separate providers for each version, but I did think (and you confirm) that a large subset of ops are common to both versions. If the implementation shares that commonality then it makes sense to at least try for one provider. Architecturally, if the differences between the two versions are sufficiently large then separate providers would be better. I''ll be happy either way though :) Nico --
I noticed that the probes are all fairly close to the protocol definition. Are there plans for other probes (eventually)? I can think of several interesting trace points in the recovery code, such as start client recovery (overall), start client recovery (specific phase, like reopening files), start/finish op, fail over to a different server, update volatile filehandle, enqueue lost request, send enqueued request, etc. Or perhaps to put it another way: will NFS4_DEBUG go away someday? mike
On Nov 15, 2007, at 7:31 PM, Adam Leventhal wrote:> On Thu, Nov 15, 2007 at 06:43:07PM -0600, Spencer Shepler wrote: >> NFSv4.1 is introducing a set of new operations to inflict the >> new set of features within the protocol. There is a mix of >> optional and mandatory to implement operations and corresponding >> args/results. That isn''t going to be a problem. The real issues >> are that there are 4-5 operations that have been designated >> as mandatory-not-to-implement; meaning that they may appear >> as defined in the RPC language but are never to be used -- >> the vestiges of NFSv4.0. That isn''t too much of a problem either. >> The larger issue is that there are a couple of arguments (OPEN >> mainly) >> that have been extended through the NFSv4 minor version rules >> to include additional parameters in effect. This means that >> an NFSv4 and NFSv4.1 provider should not share the argument >> definition. I don''t see that as much of a problem either if >> the providers were per minor version (e.g. NFSv4.0 and NFSv4.1). > > Will an NFSv4.1 server be able to handle requests from a 4.0 client? > > Are you suggesting that there will be a probe called nfsv41:::op- > open-start > which has as its argument a OPEN41args structure? It wouldn''t be > possible > to create some parameter which included the relevant information > from either > minor version?Actually, the args/results have been extended in a way that it would appear as OPEN4args in both paths. So, yes, we could extend the proposed provided to accommodate NFSv4.1 with a method of communicating which minor version is being processed. Given the differences in the minor versions, I was thinking that a method that stood out more readily to the consumer of the provider would be helpful to alleviate confusion. If there is a minor version designator, that is fine with me for the moment.> >> In summary, the proposal is fine with me as long as we have >> an expectation that a new provider (similar in size >> and complexity) will be in place for NFSv4.1. > > Yes, we''re hoping that projects groups will realize the utility of > DTrace > providers and implement them as a part of their project.Certainly. Spencer
On Thu, Nov 15, 2007 at 09:29:50AM -0800, Bill Sommerfeld wrote:> On Thu, 2007-11-15 at 01:14 -0800, Adam Leventhal wrote: > > The conninfo_t structure is already used by the iSCSI target provider (iscsi), > > and is intended for use by all provider which are providing some higher > > level protocol (e.g. iscsi, nfs, http, ftp). > > > > typedef struct conninfo { > > string ci_local; /* local host address */ > > string ci_remote; /* remote host address */ > > string ci_protocol; /* protocol (ipv4, ipv6, etc) */ > > } conninfo_t; > > For structures like this which exist only in "D" code and not in C, is > it feasible to add additional fields later?Good point -- NFSv4.1 adds a notion of "sessions" which is akin to a transport, and that will run atop TCP and SCTP, so we''ll want more information here (plus: port numbers).
On Thu, Nov 15, 2007 at 01:14:14AM -0800, Adam Leventhal wrote:> probe name args[2] > ---------- ------- > nfsv4:::compound-op-start COMPOUND4args * > nfsv4:::compound-op-done COMPOUND4res * > > ... > > nfsv4:::compound-cb-start CB_COMPOUND4args * > nfsv4:::compound-cb-done CB_COMPOUND4res *COMPOUND is an RPC, things like OPEN are ops inside a compound. So at least the names of these probes are inconsistent. Also, why not use the ''function'' part of the probes to name the operation and use "start" and "stop" for the probe names? (Am I displaying ignorance of SDT here?)
On Thu, Nov 15, 2007 at 09:29:50AM -0800, Bill Sommerfeld wrote:> On Thu, 2007-11-15 at 01:14 -0800, Adam Leventhal wrote: > > The conninfo_t structure is already used by the iSCSI target provider (iscsi), > > and is intended for use by all provider which are providing some higher > > level protocol (e.g. iscsi, nfs, http, ftp). > > > > typedef struct conninfo { > > string ci_local; /* local host address */ > > string ci_remote; /* remote host address */ > > string ci_protocol; /* protocol (ipv4, ipv6, etc) */ > > } conninfo_t; > > For structures like this which exist only in "D" code and not in C, is > it feasible to add additional fields later?Yes. Typically we only use such structs in expressions involving translators (i.e. each member of the struct is translated on-the-fly), in which case one can not only add members but also re-arrange the ordering as well. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
> > probe name args[2] > > ---------- ------- > > nfsv4:::compound-op-start COMPOUND4args * > > nfsv4:::compound-op-done COMPOUND4res * > > > > ... > > > > nfsv4:::compound-cb-start CB_COMPOUND4args * > > nfsv4:::compound-cb-done CB_COMPOUND4res * > > COMPOUND is an RPC, things like OPEN are ops inside a compound. So at > least the names of these probes are inconsistent.What names would you suggest?> Also, why not use the ''function'' part of the probes to name the > operation and use "start" and "stop" for the probe names? (Am I > displaying ignorance of SDT here?)Yes :-) The original design for this provider did exactly that, but we found its implementation more difficult than the modification was useful. Start and done are canonical names in SDT. For example, there are the io:::start and io:::done probes in the io provider. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Fri, Nov 16, 2007 at 10:53:59AM -0800, Adam Leventhal wrote:> > > probe name args[2] > > > ---------- ------- > > > nfsv4:::compound-op-start COMPOUND4args * > > > nfsv4:::compound-op-done COMPOUND4res * > > > > > > ... > > > > > > nfsv4:::compound-cb-start CB_COMPOUND4args * > > > nfsv4:::compound-cb-done CB_COMPOUND4res * > > > > COMPOUND is an RPC, things like OPEN are ops inside a compound. So at > > least the names of these probes are inconsistent. > > What names would you suggest?nfsv4:::compound-start nfsv4:::compound-done nfsv4:::compound-cb-start nfsv4:::compound-cb-done (I.e., drop the "op-" in the client->server compound direction.)> > Also, why not use the ''function'' part of the probes to name the > > operation and use "start" and "stop" for the probe names? (Am I > > displaying ignorance of SDT here?) > > Yes :-) The original design for this provider did exactly that, but we > found its implementation more difficult than the modification was useful.Thanks :)
On Fri, Nov 16, 2007 at 12:58:19PM -0600, Nicolas Williams wrote:> On Fri, Nov 16, 2007 at 10:53:59AM -0800, Adam Leventhal wrote: > > > > probe name args[2] > > > > ---------- ------- > > > > nfsv4:::compound-op-start COMPOUND4args * > > > > nfsv4:::compound-op-done COMPOUND4res * > > > > > > > > ... > > > > > > > > nfsv4:::compound-cb-start CB_COMPOUND4args * > > > > nfsv4:::compound-cb-done CB_COMPOUND4res * > > > > > > COMPOUND is an RPC, things like OPEN are ops inside a compound. So at > > > least the names of these probes are inconsistent. > > > > What names would you suggest? > > nfsv4:::compound-start > nfsv4:::compound-done > nfsv4:::compound-cb-start > nfsv4:::compound-cb-done > > (I.e., drop the "op-" in the client->server compound direction.)We chose to include ''op-'' because we thought that it created better symmetry with ''compound-cb''. The ''op-'' doesn''t indicate that it''s an operation (that would be ''op-compound-start''; rather it indicates that its the operation compound rather than the callback compound. Does that make sense? Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Nov 16, 2007, at 1:01 PM, Adam Leventhal wrote:> On Fri, Nov 16, 2007 at 12:58:19PM -0600, Nicolas Williams wrote: >> On Fri, Nov 16, 2007 at 10:53:59AM -0800, Adam Leventhal wrote: >>>>> probe name args[2] >>>>> ---------- ------- >>>>> nfsv4:::compound-op-start COMPOUND4args * >>>>> nfsv4:::compound-op-done COMPOUND4res * >>>>> >>>>> ... >>>>> >>>>> nfsv4:::compound-cb-start CB_COMPOUND4args * >>>>> nfsv4:::compound-cb-done CB_COMPOUND4res * >>>> >>>> COMPOUND is an RPC, things like OPEN are ops inside a compound. >>>> So at >>>> least the names of these probes are inconsistent. >>> >>> What names would you suggest? >> >> nfsv4:::compound-start >> nfsv4:::compound-done >> nfsv4:::compound-cb-start >> nfsv4:::compound-cb-done >> >> (I.e., drop the "op-" in the client->server compound direction.) > > We chose to include ''op-'' because we thought that it created better > symmetry > with ''compound-cb''. The ''op-'' doesn''t indicate that it''s an > operation (that > would be ''op-compound-start''; rather it indicates that its the > operation > compound rather than the callback compound.nfsv4:::compound-proc-start nfsv4:::compound-proc-done nfsv4:::compound-proc-cb-start nfsv4:::compound-proc-cb-done and to be complete nfsv4:::null-proc-start nfsv4:::null-proc-done
On Fri, Nov 16, 2007 at 03:20:02PM -0600, Spencer Shepler wrote:> >On Fri, Nov 16, 2007 at 12:58:19PM -0600, Nicolas Williams wrote: > >>On Fri, Nov 16, 2007 at 10:53:59AM -0800, Adam Leventhal wrote: > >>>>> probe name args[2] > >>>>> ---------- ------- > >>>>> nfsv4:::compound-op-start COMPOUND4args * > >>>>> nfsv4:::compound-op-done COMPOUND4res * > >>>>> > >>>>> ... > >>>>> > >>>>> nfsv4:::compound-cb-start CB_COMPOUND4args * > >>>>> nfsv4:::compound-cb-done CB_COMPOUND4res * > >>>> > >>>>COMPOUND is an RPC, things like OPEN are ops inside a compound. > >>>>So at > >>>>least the names of these probes are inconsistent. > >>> > >>>What names would you suggest? > >> > >>nfsv4:::compound-start > >>nfsv4:::compound-done > >>nfsv4:::compound-cb-start > >>nfsv4:::compound-cb-done > >> > >>(I.e., drop the "op-" in the client->server compound direction.) > > > >We chose to include ''op-'' because we thought that it created better > >symmetry > >with ''compound-cb''. The ''op-'' doesn''t indicate that it''s an > >operation (that > >would be ''op-compound-start''; rather it indicates that its the > >operation > >compound rather than the callback compound. > > nfsv4:::compound-proc-start > nfsv4:::compound-proc-done > nfsv4:::compound-proc-cb-start > nfsv4:::compound-proc-cb-done > > and to be complete > > nfsv4:::null-proc-start > nfsv4:::null-proc-doneWhy is that better? Can you explain a bit? It still seems as though you''re still losing the symmetry between the compound operations and callbacks, but perhaps that''s intentional. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Fri, Nov 16, 2007 at 01:53:05PM -0800, Adam Leventhal wrote:> On Fri, Nov 16, 2007 at 03:20:02PM -0600, Spencer Shepler wrote: > > >On Fri, Nov 16, 2007 at 12:58:19PM -0600, Nicolas Williams wrote: > > >>(I.e., drop the "op-" in the client->server compound direction.) > > > > > >We chose to include ''op-'' because we thought that it created better > > >symmetry with ''compound-cb''. The ''op-'' doesn''t indicate that it''s > > >an operation (that would be ''op-compound-start''; rather it > > >indicates that its the operation compound rather than the callback > > >compound. > > > > nfsv4:::compound-proc-start > > nfsv4:::compound-proc-done > > nfsv4:::compound-proc-cb-start > > nfsv4:::compound-proc-cb-done > > > > and to be complete > > > > nfsv4:::null-proc-start > > nfsv4:::null-proc-done > > Why is that better? Can you explain a bit? It still seems as though you''re > still losing the symmetry between the compound operations and callbacks, but > perhaps that''s intentional.I don''t see that. I think what Spencer and I are saying is that COMPOUND is not an operation, but a procedure. And folks who know the protocol would expect the probe naming to reflect the procedure vs. operation distinction. It''s mostly six of one and half-a-dozen of the other, but suppose v4.2 added a COMPOUND OP (no, I''m sure that wouldn''t happen)... I think the simplest thing to do is to let the probe names reflect the protocol element names wherever probes relate directly to protocol elements. It may be wordier, but it will be less surprising to those who know the protocol (and yes, I realize that the proponents here know the protocol, much better than I know it too). Nico --
On Fri, Nov 16, 2007 at 04:07:13PM -0600, Nicolas Williams wrote:> It''s mostly six of one and half-a-dozen of the other, but suppose v4.2 > added a COMPOUND OP (no, I''m sure that wouldn''t happen)...Then that would be op-compound rather than compound-op. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Nov 16, 2007, at 3:53 PM, Adam Leventhal wrote:> On Fri, Nov 16, 2007 at 03:20:02PM -0600, Spencer Shepler wrote: >>> On Fri, Nov 16, 2007 at 12:58:19PM -0600, Nicolas Williams wrote: >>>> On Fri, Nov 16, 2007 at 10:53:59AM -0800, Adam Leventhal wrote: >>>>>>> probe name args[2] >>>>>>> ---------- ------- >>>>>>> nfsv4:::compound-op-start COMPOUND4args * >>>>>>> nfsv4:::compound-op-done COMPOUND4res * >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> nfsv4:::compound-cb-start CB_COMPOUND4args * >>>>>>> nfsv4:::compound-cb-done CB_COMPOUND4res * >>>>>> >>>>>> COMPOUND is an RPC, things like OPEN are ops inside a compound. >>>>>> So at >>>>>> least the names of these probes are inconsistent. >>>>> >>>>> What names would you suggest? >>>> >>>> nfsv4:::compound-start >>>> nfsv4:::compound-done >>>> nfsv4:::compound-cb-start >>>> nfsv4:::compound-cb-done >>>> >>>> (I.e., drop the "op-" in the client->server compound direction.) >>> >>> We chose to include ''op-'' because we thought that it created better >>> symmetry >>> with ''compound-cb''. The ''op-'' doesn''t indicate that it''s an >>> operation (that >>> would be ''op-compound-start''; rather it indicates that its the >>> operation >>> compound rather than the callback compound. >> >> nfsv4:::compound-proc-start >> nfsv4:::compound-proc-done >> nfsv4:::compound-proc-cb-start >> nfsv4:::compound-proc-cb-done >> >> and to be complete >> >> nfsv4:::null-proc-start >> nfsv4:::null-proc-done > > Why is that better? Can you explain a bit? It still seems as though > you''re > still losing the symmetry between the compound operations and > callbacks, but > perhaps that''s intentional."proc" => procedure and that is what NULL and COMPOUND are. They are procedures. The "operations" are NFSv4 inventions and not part of the RPC/XDR nomenclature. The reason I didn''t suggest "proc-forward" and "proc-callback" is that normally "proc" is known to be the client initiating interaction with the server and left the naming such that it would be implied. I don''t have a strong opinion here. Suggestion has been made and the project team can choose whether to utilize it. Spencer
On Sat, Nov 17, 2007 at 11:23:35PM -0600, Spencer Shepler wrote:> I don''t have a strong opinion here. Suggestion has been made and > the project team can choose whether to utilize it.Cool. We''ll slosh through a couple of possibilities and try to come up with one that makes sense. ADam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
Brendan Gregg - Sun Microsystems
2007-Nov-19 22:25 UTC
[dtrace-discuss] provider proposal: NFS v4
G''Day, On Sat, Nov 17, 2007 at 11:23:35PM -0600, Spencer Shepler wrote:> > On Nov 16, 2007, at 3:53 PM, Adam Leventhal wrote: > > > On Fri, Nov 16, 2007 at 03:20:02PM -0600, Spencer Shepler wrote:[...]> >> nfsv4:::compound-proc-start > >> nfsv4:::compound-proc-done > >> nfsv4:::compound-proc-cb-start > >> nfsv4:::compound-proc-cb-done > >> > >> and to be complete > >> > >> nfsv4:::null-proc-start > >> nfsv4:::null-proc-done > > > > Why is that better? Can you explain a bit? It still seems as though > > you''re > > still losing the symmetry between the compound operations and > > callbacks, but > > perhaps that''s intentional. > > "proc" => procedureYes, "proc" sounds too much like process; however "procedure" sounds like something new I didn''t know about in NFSv4.> and that is what NULL and COMPOUND are. They are procedures. > The "operations" are NFSv4 inventions and not part of the > RPC/XDR nomenclature.While I''m sure that''s true, from what I''ve read about NFSv4 the terms "compound" and "operation" are familiar, and the term "procedure" isn''t. eg, http://www.nasconf.com/pres04/spencer.pdf Sorry, I''m not picking your own presentation to make a point, rather it was the first docs I found when googling. :-) Anyhow, that''s just my opinion as an end-user. cheers, Brendan -- Brendan [CA, USA]
On Mon, Nov 19, 2007 at 02:25:02PM -0800, Brendan Gregg - Sun Microsystems wrote:> > "proc" => procedure > > Yes, "proc" sounds too much like process; however "procedure" sounds like > something new I didn''t know about in NFSv4."Procedure" is part of ONC/RPC (NFS being an ONC/RPC "program") and goes back ~20 years (more when you consider the other, then popular RPC frameworks).> > and that is what NULL and COMPOUND are. They are procedures. > > The "operations" are NFSv4 inventions and not part of the > > RPC/XDR nomenclature. > > While I''m sure that''s true, from what I''ve read about NFSv4 the terms > "compound" and "operation" are familiar, and the term "procedure" isn''t.Well, NFSv2/3 never had compounds nor operations -- they only had procedures. So, "proc" is nothing new. OTOH, there''s only two procs in NFSv4: NULL (required of all ONC/RPC "programs" and used only for pinging) and COMPOUND, and you could argue that there will/should not be a probe for PING and that since all ops will happen through a COMPOUND then "proc" would be a tad redundant. Nico --
Brendan Gregg - Sun Microsystems
2007-Nov-19 23:18 UTC
[dtrace-discuss] provider proposal: NFS v4
On Mon, Nov 19, 2007 at 04:36:30PM -0600, Nicolas Williams wrote:> On Mon, Nov 19, 2007 at 02:25:02PM -0800, Brendan Gregg - Sun Microsystems wrote: > > > "proc" => procedure > > > > Yes, "proc" sounds too much like process; however "procedure" sounds like > > something new I didn''t know about in NFSv4. > > "Procedure" is part of ONC/RPC (NFS being an ONC/RPC "program") and goes > back ~20 years (more when you consider the other, then popular RPC > frameworks). > > > > and that is what NULL and COMPOUND are. They are procedures. > > > The "operations" are NFSv4 inventions and not part of the > > > RPC/XDR nomenclature. > > > > While I''m sure that''s true, from what I''ve read about NFSv4 the terms > > "compound" and "operation" are familiar, and the term "procedure" isn''t. > > Well, NFSv2/3 never had compounds nor operations -- they only had > procedures. So, "proc" is nothing new.It is something new, for customers who have read Sun''s documentation - which was my point. "Many Solaris NFS version 3 operations return the file attributes," http://docs.sun.com/app/docs/doc/816-4555/6maoqui8f?a=view Good luck finding "procedure" used in the exact same context. Sun''s use of "operation" to mean "procedure" goes back many years. Brendan -- Brendan [CA, USA]
On Nov 19, 2007, at 4:18 PM, Brendan Gregg - Sun Microsystems wrote:> On Mon, Nov 19, 2007 at 04:36:30PM -0600, Nicolas Williams wrote: >> On Mon, Nov 19, 2007 at 02:25:02PM -0800, Brendan Gregg - Sun >> Microsystems wrote: >>>> "proc" => procedure >>> >>> Yes, "proc" sounds too much like process; however "procedure" >>> sounds like >>> something new I didn''t know about in NFSv4. >> >> "Procedure" is part of ONC/RPC (NFS being an ONC/RPC "program") >> and goes >> back ~20 years (more when you consider the other, then popular RPC >> frameworks). >> >>>> and that is what NULL and COMPOUND are. They are procedures. >>>> The "operations" are NFSv4 inventions and not part of the >>>> RPC/XDR nomenclature. >>> >>> While I''m sure that''s true, from what I''ve read about NFSv4 the >>> terms >>> "compound" and "operation" are familiar, and the term "procedure" >>> isn''t. >> >> Well, NFSv2/3 never had compounds nor operations -- they only had >> procedures. So, "proc" is nothing new. > > It is something new, for customers who have read Sun''s documentation - > which was my point. > > "Many Solaris NFS version 3 operations return the file attributes," > http://docs.sun.com/app/docs/doc/816-4555/6maoqui8f?a=view > > Good luck finding "procedure" used in the exact same context. > Sun''s use > of "operation" to mean "procedure" goes back many years. >A slightly different proposal... how about: nfsv4:::compound-start nfsv4:::compound-done nfsv4:::cb-compound-start nfsv4:::cb-compound-done Why this? 1. It is correct from a NFSv4 RPC program point of view. 2. "proc" isn''t there to cause confusion. 3. It is fewer characters to type. Thanks, Lisa
On Mon, Nov 19, 2007 at 04:21:10PM -0700, Lisa Week wrote:> A slightly different proposal... how about: > > nfsv4:::compound-start > nfsv4:::compound-done > > nfsv4:::cb-compound-start > nfsv4:::cb-compound-done > > > Why this? > 1. It is correct from a NFSv4 RPC program point of view. > 2. "proc" isn''t there to cause confusion. > 3. It is fewer characters to type.4. It''s consistent. (The original proposal had "op-" for the forward compount probe names, but not for the callback probe names.) (1), (3) and (4) are sufficient for *my* tastes :)
On 16 Nov 2007, at 04:51, Spencer Shepler wrote:> Actually, the args/results have been extended in a way that > it would appear as OPEN4args in both paths. So, yes, we could > extend the proposed provided to accommodate NFSv4.1 with a method > of communicating which minor version is being processed. > Given the differences in the minor versions, I was thinking that > a method that stood out more readily to the consumer of the provider > would be helpful to alleviate confusion.If I was dtracing an NFSv4 problem, I would at first not expect to have to differentiate between NFSv4.0 and NFSv4.1. Is this wrong? Are the two a completely different code path for the above mentioned open? I would be confused by different providers. And a day earlier Adam wrote:> The plan is to have a different provider; either nfsv4c or > nfsv4client or something.I assume this is all talking about an NFS v4 server provider, guessing by the discussion and the FishWorks signature. Any NFS v4 client provider in sight? We have far more NFS clients than NFS servers to troubleshoot. Why would the nfsv4 client provider be called nfsv4c or nfsv4client, but the server just nfsv4? I would find that rather confusing as a user. - mo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20071119/58511eb4/attachment.bin>
On Mon, Nov 19, 2007 at 11:34:00PM +0000, Moritz Willers wrote:> >The plan is to have a different provider; either nfsv4c or > >nfsv4client or something. > > I assume this is all talking about an NFS v4 server provider, guessing > by the discussion and the FishWorks signature. Any NFS v4 client > provider in sight? We have far more NFS clients than NFS servers to > troubleshoot. Why would the nfsv4 client provider be called nfsv4c or > nfsv4client, but the server just nfsv4? I would find that rather > confusing as a user.We decided awhile ago that servers would take the name of the protocol and clients would have some extension appended. For example, we have the ''iscsi'' provider, and will have ''http'' and ''ftp'' providers. By extension, the NFS server-side providers will be called nfsv3 and nfsv4. We thought about having a single provider for both client and server, but thought that would be confusing or would lead to extremely long probe names. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Nov 19, 2007, at 5:34 PM, Moritz Willers wrote:> > On 16 Nov 2007, at 04:51, Spencer Shepler wrote: > >> Actually, the args/results have been extended in a way that >> it would appear as OPEN4args in both paths. So, yes, we could >> extend the proposed provided to accommodate NFSv4.1 with a method >> of communicating which minor version is being processed. >> Given the differences in the minor versions, I was thinking that >> a method that stood out more readily to the consumer of the provider >> would be helpful to alleviate confusion. > > If I was dtracing an NFSv4 problem, I would at first not expect to > have to differentiate between NFSv4.0 and NFSv4.1. Is this wrong? > Are the two a completely different code path for the above > mentioned open? I would be confused by different providers.As you note, .0 and .1 are minor versions of the overall NFSv4 protocol. Unfortuntaely, that english description hides the impact of the additional operations in 4.1 and the fact that the Sessions related functionality is "mandatory to implement" in the minor version. The other thing to note is that protocol state from one minor version (namely filehandles) can not be used in one of the other minor versions. So, it turns out that clients will make a choice of minor version for a mount and stick to it; just as they do today with NFSv3 and NFSv4. This behavior is likely more to the point. Spencer
On Nov 19, 2007, at 4:25 PM, Brendan Gregg - Sun Microsystems wrote:> G''Day, > > On Sat, Nov 17, 2007 at 11:23:35PM -0600, Spencer Shepler wrote: >> >> On Nov 16, 2007, at 3:53 PM, Adam Leventhal wrote: >> >>> On Fri, Nov 16, 2007 at 03:20:02PM -0600, Spencer Shepler wrote: > [...] >>>> nfsv4:::compound-proc-start >>>> nfsv4:::compound-proc-done >>>> nfsv4:::compound-proc-cb-start >>>> nfsv4:::compound-proc-cb-done >>>> >>>> and to be complete >>>> >>>> nfsv4:::null-proc-start >>>> nfsv4:::null-proc-done >>> >>> Why is that better? Can you explain a bit? It still seems as though >>> you''re >>> still losing the symmetry between the compound operations and >>> callbacks, but >>> perhaps that''s intentional. >> >> "proc" => procedure > > Yes, "proc" sounds too much like process; however "procedure" > sounds like > something new I didn''t know about in NFSv4. > >> and that is what NULL and COMPOUND are. They are procedures. >> The "operations" are NFSv4 inventions and not part of the >> RPC/XDR nomenclature. > > While I''m sure that''s true, from what I''ve read about NFSv4 the terms > "compound" and "operation" are familiar, and the term "procedure" > isn''t. > eg, > http://www.nasconf.com/pres04/spencer.pdf > > Sorry, I''m not picking your own presentation to make a point, > rather it > was the first docs I found when googling. :-)Heh, that is funny.> > Anyhow, that''s just my opinion as an end-user. >Sure. As mentioned, I don''t have a strong opinion about it. Spencer