diff mbox

nfsstat: reorder nfs4 stats for 2.6.38 and up

Message ID 1303461980-6731-1-git-send-email-bhalevy@panasas.com (mailing list archive)
State New, archived
Headers show

Commit Message

Benny Halevy April 22, 2011, 8:46 a.m. UTC 
match order in 2.6.38, 2.6.39 (-rc3) and development tree
while at it, get rid of obsolete ds_write and ds_commit

Signed-off-by: Benny Halevy <bhalevy@panasas.com>
---
 utils/nfsstat/nfsstat.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

git://linux-nfs.org/~bhalevy/pnfs-nfs-utils.git
updated respectively

Comments

Benny Halevy April 27, 2011, 4:50 a.m. UTC | #1 
On 2011-04-25 17:11, Chuck Lever wrote:
> Hey all-
> 
> So what are we going to do when adding NFSv4.2 to this mix?  Will we
> then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
> kernel?  Seems painful.

Good question.
How about changing the stat pseudo-file format to include an op
identifier along with its respective counter, printing a line per op?

Benny

> 
> On Apr 22, 2011, at 4:46 AM, Benny Halevy wrote:
> 
>> match order in 2.6.38, 2.6.39 (-rc3) and development tree while at
>> it, get rid of obsolete ds_write and ds_commit
>> 
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com> --- 
>> utils/nfsstat/nfsstat.c |    5 +---- 1 files changed, 1
>> insertions(+), 4 deletions(-)
>> 
>> git://linux-nfs.org/~bhalevy/pnfs-nfs-utils.git updated
>> respectively
>> 
>> diff --git a/utils/nfsstat/nfsstat.c b/utils/nfsstat/nfsstat.c 
>> index f31bb81..a4a8034 100644 --- a/utils/nfsstat/nfsstat.c +++
>> b/utils/nfsstat/nfsstat.c @@ -126,14 +126,11 @@ static const char *
>> nfscltproc4name[CLTPROC4_SZ] = { "sequence", "get_lease_t", 
>> "reclaim_comp", +	"getdevinfo", "layoutget", "layoutcommit", 
>> "layoutreturn", "getdevlist", -	"getdevinfo", -	/* nfsv4.1 pnfs
>> client ops to data server only */ -	"ds_write", -	"ds_commit", };
>> 
>> static const char *     nfssrvproc4opname[SRVPROC4OPS_SZ] = { -- 
>> 1.7.3.4
>> 
>> -- To unsubscribe from this list: send the line "unsubscribe
>> linux-nfs" in the body of a message to majordomo@vger.kernel.org 
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Trond Myklebust April 27, 2011, 2:16 p.m. UTC | #2 
On Wed, 2011-04-27 at 07:50 +0300, Benny Halevy wrote:
> On 2011-04-25 17:11, Chuck Lever wrote:
> > Hey all-
> > 
> > So what are we going to do when adding NFSv4.2 to this mix?  Will we
> > then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
> > kernel?  Seems painful.
> 
> Good question.
> How about changing the stat pseudo-file format to include an op
> identifier along with its respective counter, printing a line per op?

We already have that in /proc/self/mountstats
Benny Halevy April 27, 2011, 6:52 p.m. UTC | #3 
On 2011-04-27 17:16, Trond Myklebust wrote:
> On Wed, 2011-04-27 at 07:50 +0300, Benny Halevy wrote:
>> On 2011-04-25 17:11, Chuck Lever wrote:
>>> Hey all-
>>>
>>> So what are we going to do when adding NFSv4.2 to this mix?  Will we
>>> then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
>>> kernel?  Seems painful.
>>
>> Good question.
>> How about changing the stat pseudo-file format to include an op
>> identifier along with its respective counter, printing a line per op?
> 
> We already have that in /proc/self/mountstats
> 
> 

You mean /proc/self/status?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Trond Myklebust April 27, 2011, 6:58 p.m. UTC | #4 
On Wed, 2011-04-27 at 21:52 +0300, Benny Halevy wrote:
> On 2011-04-27 17:16, Trond Myklebust wrote:
> > On Wed, 2011-04-27 at 07:50 +0300, Benny Halevy wrote:
> >> On 2011-04-25 17:11, Chuck Lever wrote:
> >>> Hey all-
> >>>
> >>> So what are we going to do when adding NFSv4.2 to this mix?  Will we
> >>> then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
> >>> kernel?  Seems painful.
> >>
> >> Good question.
> >> How about changing the stat pseudo-file format to include an op
> >> identifier along with its respective counter, printing a line per op?
> > 
> > We already have that in /proc/self/mountstats
> > 
> > 
> 
> You mean /proc/self/status?

No.
Benny Halevy April 27, 2011, 8:24 p.m. UTC | #5 
On 2011-04-27 21:58, Trond Myklebust wrote:
> On Wed, 2011-04-27 at 21:52 +0300, Benny Halevy wrote:
>> On 2011-04-27 17:16, Trond Myklebust wrote:
>>> On Wed, 2011-04-27 at 07:50 +0300, Benny Halevy wrote:
>>>> On 2011-04-25 17:11, Chuck Lever wrote:
>>>>> Hey all-
>>>>>
>>>>> So what are we going to do when adding NFSv4.2 to this mix?  Will we
>>>>> then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
>>>>> kernel?  Seems painful.
>>>>
>>>> Good question.
>>>> How about changing the stat pseudo-file format to include an op
>>>> identifier along with its respective counter, printing a line per op?
>>>
>>> We already have that in /proc/self/mountstats
>>>
>>>
>>
>> You mean /proc/self/status?
> 
> No.

So can you please explain what you meant by the /proc/self/mountstats
example?

This is what I see:

$ head -3 /proc/self/mountstats
device rootfs mounted on / with fstype rootfs
device /proc mounted on /proc with fstype proc
device /sys mounted on /sys with fstype sysfs

Benny

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Trond Myklebust April 27, 2011, 8:29 p.m. UTC | #6 
On Wed, 2011-04-27 at 23:24 +0300, Benny Halevy wrote:
> On 2011-04-27 21:58, Trond Myklebust wrote:
> > On Wed, 2011-04-27 at 21:52 +0300, Benny Halevy wrote:
> >> On 2011-04-27 17:16, Trond Myklebust wrote:
> >>> On Wed, 2011-04-27 at 07:50 +0300, Benny Halevy wrote:
> >>>> On 2011-04-25 17:11, Chuck Lever wrote:
> >>>>> Hey all-
> >>>>>
> >>>>> So what are we going to do when adding NFSv4.2 to this mix?  Will we
> >>>>> then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
> >>>>> kernel?  Seems painful.
> >>>>
> >>>> Good question.
> >>>> How about changing the stat pseudo-file format to include an op
> >>>> identifier along with its respective counter, printing a line per op?
> >>>
> >>> We already have that in /proc/self/mountstats
> >>>
> >>>
> >>
> >> You mean /proc/self/status?
> > 
> > No.
> 
> So can you please explain what you meant by the /proc/self/mountstats
> example?
> 
> This is what I see:
> 
> $ head -3 /proc/self/mountstats
> device rootfs mounted on / with fstype rootfs
> device /proc mounted on /proc with fstype proc
> device /sys mounted on /sys with fstype sysfs
> 
> Benny

Try mounting an NFS partition. When I do, I also get:

device ila.local:/raid0/data/vol0 mounted on /net/ila.local/raid0/data/vol0 with fstype nfs statvers=1.0
	opts:	rw,vers=3,rsize=32768,wsize=32768,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.20,mountvers=3,mountport=993,mountproto=udp
	age:	3
	caps:	caps=0x3fcf,wtmult=4096,dtsize=4096,bsize=0,namlen=255
	sec:	flavor=1,pseudoflavor=1
	events:	4 101 0 0 6 0 107 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 
	bytes:	0 0 0 0 0 0 0 0 
	RPC iostats version: 1.0  p/v: 100003/3 (nfs)
	xprt:	tcp 826 1 1 0 2 24 24 0 24 0
	per-op statistics
	        NULL: 0 0 0 0 0 0 0 0
	     GETATTR: 6 6 0 752 672 0 1 1
	     SETATTR: 0 0 0 0 0 0 0 0
	      LOOKUP: 0 0 0 0 0 0 0 0
	      ACCESS: 5 5 0 692 600 0 1 1
	    READLINK: 0 0 0 0 0 0 0 0
	        READ: 0 0 0 0 0 0 0 0
	       WRITE: 0 0 0 0 0 0 0 0
	      CREATE: 0 0 0 0 0 0 0 0
	       MKDIR: 0 0 0 0 0 0 0 0
	     SYMLINK: 0 0 0 0 0 0 0 0
	       MKNOD: 0 0 0 0 0 0 0 0
	      REMOVE: 0 0 0 0 0 0 0 0
	       RMDIR: 0 0 0 0 0 0 0 0
	      RENAME: 0 0 0 0 0 0 0 0
	        LINK: 0 0 0 0 0 0 0 0
	     READDIR: 0 0 0 0 0 0 0 0
	 READDIRPLUS: 7 7 0 1112 13832 0 35 36
	      FSSTAT: 1 1 0 104 84 0 1 1
	      FSINFO: 2 2 0 208 160 0 0 0
	    PATHCONF: 1 1 0 104 56 0 0 0
	      COMMIT: 0 0 0 0 0 0 0 0

Providing this kind of statistic was _exactly_ the reason for adding
mountstats in the first place.
Benny Halevy April 27, 2011, 8:33 p.m. UTC | #7 
On 2011-04-27 23:29, Trond Myklebust wrote:
> On Wed, 2011-04-27 at 23:24 +0300, Benny Halevy wrote:
>> On 2011-04-27 21:58, Trond Myklebust wrote:
>>> On Wed, 2011-04-27 at 21:52 +0300, Benny Halevy wrote:
>>>> On 2011-04-27 17:16, Trond Myklebust wrote:
>>>>> On Wed, 2011-04-27 at 07:50 +0300, Benny Halevy wrote:
>>>>>> On 2011-04-25 17:11, Chuck Lever wrote:
>>>>>>> Hey all-
>>>>>>>
>>>>>>> So what are we going to do when adding NFSv4.2 to this mix?  Will we
>>>>>>> then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
>>>>>>> kernel?  Seems painful.
>>>>>>
>>>>>> Good question.
>>>>>> How about changing the stat pseudo-file format to include an op
>>>>>> identifier along with its respective counter, printing a line per op?
>>>>>
>>>>> We already have that in /proc/self/mountstats
>>>>>
>>>>>
>>>>
>>>> You mean /proc/self/status?
>>>
>>> No.
>>
>> So can you please explain what you meant by the /proc/self/mountstats
>> example?
>>
>> This is what I see:
>>
>> $ head -3 /proc/self/mountstats
>> device rootfs mounted on / with fstype rootfs
>> device /proc mounted on /proc with fstype proc
>> device /sys mounted on /sys with fstype sysfs
>>
>> Benny
> 
> Try mounting an NFS partition. When I do, I also get:
> 
> device ila.local:/raid0/data/vol0 mounted on /net/ila.local/raid0/data/vol0 with fstype nfs statvers=1.0
> 	opts:	rw,vers=3,rsize=32768,wsize=32768,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.20,mountvers=3,mountport=993,mountproto=udp
> 	age:	3
> 	caps:	caps=0x3fcf,wtmult=4096,dtsize=4096,bsize=0,namlen=255
> 	sec:	flavor=1,pseudoflavor=1
> 	events:	4 101 0 0 6 0 107 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 
> 	bytes:	0 0 0 0 0 0 0 0 
> 	RPC iostats version: 1.0  p/v: 100003/3 (nfs)
> 	xprt:	tcp 826 1 1 0 2 24 24 0 24 0
> 	per-op statistics
> 	        NULL: 0 0 0 0 0 0 0 0
> 	     GETATTR: 6 6 0 752 672 0 1 1
> 	     SETATTR: 0 0 0 0 0 0 0 0
> 	      LOOKUP: 0 0 0 0 0 0 0 0
> 	      ACCESS: 5 5 0 692 600 0 1 1
> 	    READLINK: 0 0 0 0 0 0 0 0
> 	        READ: 0 0 0 0 0 0 0 0
> 	       WRITE: 0 0 0 0 0 0 0 0
> 	      CREATE: 0 0 0 0 0 0 0 0
> 	       MKDIR: 0 0 0 0 0 0 0 0
> 	     SYMLINK: 0 0 0 0 0 0 0 0
> 	       MKNOD: 0 0 0 0 0 0 0 0
> 	      REMOVE: 0 0 0 0 0 0 0 0
> 	       RMDIR: 0 0 0 0 0 0 0 0
> 	      RENAME: 0 0 0 0 0 0 0 0
> 	        LINK: 0 0 0 0 0 0 0 0
> 	     READDIR: 0 0 0 0 0 0 0 0
> 	 READDIRPLUS: 7 7 0 1112 13832 0 35 36
> 	      FSSTAT: 1 1 0 104 84 0 1 1
> 	      FSINFO: 2 2 0 208 160 0 0 0
> 	    PATHCONF: 1 1 0 104 56 0 0 0
> 	      COMMIT: 0 0 0 0 0 0 0 0
> 
> Providing this kind of statistic was _exactly_ the reason for adding
> mountstats in the first place.

Ah, cool!
This makes much more sense now :)

Benny
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Steve Dickson April 27, 2011, 9:05 p.m. UTC | #8 
On 04/27/2011 04:33 PM, Benny Halevy wrote:
> On 2011-04-27 23:29, Trond Myklebust wrote:
>> On Wed, 2011-04-27 at 23:24 +0300, Benny Halevy wrote:
>>> On 2011-04-27 21:58, Trond Myklebust wrote:
>>>> On Wed, 2011-04-27 at 21:52 +0300, Benny Halevy wrote:
>>>>> On 2011-04-27 17:16, Trond Myklebust wrote:
>>>>>> On Wed, 2011-04-27 at 07:50 +0300, Benny Halevy wrote:
>>>>>>> On 2011-04-25 17:11, Chuck Lever wrote:
>>>>>>>> Hey all-
>>>>>>>>
>>>>>>>> So what are we going to do when adding NFSv4.2 to this mix?  Will we
>>>>>>>> then have to freeze both the NFSv4.1 and NFSv4.0 procedure API in the
>>>>>>>> kernel?  Seems painful.
>>>>>>>
>>>>>>> Good question.
>>>>>>> How about changing the stat pseudo-file format to include an op
>>>>>>> identifier along with its respective counter, printing a line per op?
>>>>>>
>>>>>> We already have that in /proc/self/mountstats
>>>>>>
>>>>>>
>>>>>
>>>>> You mean /proc/self/status?
>>>>
>>>> No.
>>>
>>> So can you please explain what you meant by the /proc/self/mountstats
>>> example?
>>>
>>> This is what I see:
>>>
>>> $ head -3 /proc/self/mountstats
>>> device rootfs mounted on / with fstype rootfs
>>> device /proc mounted on /proc with fstype proc
>>> device /sys mounted on /sys with fstype sysfs
>>>
>>> Benny
>>
>> Try mounting an NFS partition. When I do, I also get:
>>
>> device ila.local:/raid0/data/vol0 mounted on /net/ila.local/raid0/data/vol0 with fstype nfs statvers=1.0
>> 	opts:	rw,vers=3,rsize=32768,wsize=32768,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.20,mountvers=3,mountport=993,mountproto=udp
>> 	age:	3
>> 	caps:	caps=0x3fcf,wtmult=4096,dtsize=4096,bsize=0,namlen=255
>> 	sec:	flavor=1,pseudoflavor=1
>> 	events:	4 101 0 0 6 0 107 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 
>> 	bytes:	0 0 0 0 0 0 0 0 
>> 	RPC iostats version: 1.0  p/v: 100003/3 (nfs)
>> 	xprt:	tcp 826 1 1 0 2 24 24 0 24 0
>> 	per-op statistics
>> 	        NULL: 0 0 0 0 0 0 0 0
>> 	     GETATTR: 6 6 0 752 672 0 1 1
>> 	     SETATTR: 0 0 0 0 0 0 0 0
>> 	      LOOKUP: 0 0 0 0 0 0 0 0
>> 	      ACCESS: 5 5 0 692 600 0 1 1
>> 	    READLINK: 0 0 0 0 0 0 0 0
>> 	        READ: 0 0 0 0 0 0 0 0
>> 	       WRITE: 0 0 0 0 0 0 0 0
>> 	      CREATE: 0 0 0 0 0 0 0 0
>> 	       MKDIR: 0 0 0 0 0 0 0 0
>> 	     SYMLINK: 0 0 0 0 0 0 0 0
>> 	       MKNOD: 0 0 0 0 0 0 0 0
>> 	      REMOVE: 0 0 0 0 0 0 0 0
>> 	       RMDIR: 0 0 0 0 0 0 0 0
>> 	      RENAME: 0 0 0 0 0 0 0 0
>> 	        LINK: 0 0 0 0 0 0 0 0
>> 	     READDIR: 0 0 0 0 0 0 0 0
>> 	 READDIRPLUS: 7 7 0 1112 13832 0 35 36
>> 	      FSSTAT: 1 1 0 104 84 0 1 1
>> 	      FSINFO: 2 2 0 208 160 0 0 0
>> 	    PATHCONF: 1 1 0 104 56 0 0 0
>> 	      COMMIT: 0 0 0 0 0 0 0 0
>>
>> Providing this kind of statistic was _exactly_ the reason for adding
>> mountstats in the first place.
> 
> Ah, cool!
> This makes much more sense now :)
FYI... both mountstats and nfsiostat using this file...

steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Steve Dickson May 23, 2011, 12:39 p.m. UTC | #9 
On 04/22/2011 04:46 AM, Benny Halevy wrote:
> match order in 2.6.38, 2.6.39 (-rc3) and development tree
> while at it, get rid of obsolete ds_write and ds_commit
> 
> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
> ---
>  utils/nfsstat/nfsstat.c |    5 +----
>  1 files changed, 1 insertions(+), 4 deletions(-)
> 
> git://linux-nfs.org/~bhalevy/pnfs-nfs-utils.git
> updated respectively
> 
> diff --git a/utils/nfsstat/nfsstat.c b/utils/nfsstat/nfsstat.c
> index f31bb81..a4a8034 100644
> --- a/utils/nfsstat/nfsstat.c
> +++ b/utils/nfsstat/nfsstat.c
> @@ -126,14 +126,11 @@ static const char *	nfscltproc4name[CLTPROC4_SZ] = {
>  	"sequence",
>  	"get_lease_t",
>  	"reclaim_comp",
> +	"getdevinfo",
>  	"layoutget",
>  	"layoutcommit",
>  	"layoutreturn",
>  	"getdevlist",
> -	"getdevinfo",
> -	/* nfsv4.1 pnfs client ops to data server only */
> -	"ds_write",
> -	"ds_commit",
>  };
>  
>  static const char *     nfssrvproc4opname[SRVPROC4OPS_SZ] = {
Committed...

steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/utils/nfsstat/nfsstat.c b/utils/nfsstat/nfsstat.c
index f31bb81..a4a8034 100644
--- a/utils/nfsstat/nfsstat.c
+++ b/utils/nfsstat/nfsstat.c
@@ -126,14 +126,11 @@  static const char *	nfscltproc4name[CLTPROC4_SZ] = {
 	"sequence",
 	"get_lease_t",
 	"reclaim_comp",
+	"getdevinfo",
 	"layoutget",
 	"layoutcommit",
 	"layoutreturn",
 	"getdevlist",
-	"getdevinfo",
-	/* nfsv4.1 pnfs client ops to data server only */
-	"ds_write",
-	"ds_commit",
 };
 
 static const char *     nfssrvproc4opname[SRVPROC4OPS_SZ] = {