* [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
@ 2011-04-22 8:46 Benny Halevy
2011-04-25 14:11 ` Chuck Lever
2011-05-23 12:39 ` Steve Dickson
0 siblings, 2 replies; 11+ messages in thread
From: Benny Halevy @ 2011-04-22 8:46 UTC (permalink / raw)
To: steved; +Cc: linux-nfs
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-22 8:46 [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up Benny Halevy
@ 2011-04-25 14:11 ` Chuck Lever
2011-04-27 4:50 ` Benny Halevy
2011-05-23 12:39 ` Steve Dickson
1 sibling, 1 reply; 11+ messages in thread
From: Chuck Lever @ 2011-04-25 14:11 UTC (permalink / raw)
To: Benny Halevy; +Cc: steved, linux-nfs
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.
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
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-25 14:11 ` Chuck Lever
@ 2011-04-27 4:50 ` Benny Halevy
2011-04-27 14:16 ` Trond Myklebust
0 siblings, 1 reply; 11+ messages in thread
From: Benny Halevy @ 2011-04-27 4:50 UTC (permalink / raw)
To: Chuck Lever; +Cc: steved, linux-nfs
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-27 4:50 ` Benny Halevy
@ 2011-04-27 14:16 ` Trond Myklebust
2011-04-27 18:52 ` Benny Halevy
0 siblings, 1 reply; 11+ messages in thread
From: Trond Myklebust @ 2011-04-27 14:16 UTC (permalink / raw)
To: Benny Halevy; +Cc: Chuck Lever, steved, linux-nfs
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
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-27 14:16 ` Trond Myklebust
@ 2011-04-27 18:52 ` Benny Halevy
2011-04-27 18:58 ` Trond Myklebust
0 siblings, 1 reply; 11+ messages in thread
From: Benny Halevy @ 2011-04-27 18:52 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, steved, linux-nfs
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-27 18:52 ` Benny Halevy
@ 2011-04-27 18:58 ` Trond Myklebust
2011-04-27 20:24 ` Benny Halevy
0 siblings, 1 reply; 11+ messages in thread
From: Trond Myklebust @ 2011-04-27 18:58 UTC (permalink / raw)
To: Benny Halevy; +Cc: Chuck Lever, steved, linux-nfs
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.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-27 18:58 ` Trond Myklebust
@ 2011-04-27 20:24 ` Benny Halevy
2011-04-27 20:29 ` Trond Myklebust
0 siblings, 1 reply; 11+ messages in thread
From: Benny Halevy @ 2011-04-27 20:24 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, steved, linux-nfs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-27 20:24 ` Benny Halevy
@ 2011-04-27 20:29 ` Trond Myklebust
[not found] ` <1303936194.28589.2.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Trond Myklebust @ 2011-04-27 20:29 UTC (permalink / raw)
To: Benny Halevy; +Cc: Chuck Lever, steved, linux-nfs
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.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
[not found] ` <1303936194.28589.2.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
@ 2011-04-27 20:33 ` Benny Halevy
2011-04-27 21:05 ` Steve Dickson
0 siblings, 1 reply; 11+ messages in thread
From: Benny Halevy @ 2011-04-27 20:33 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, steved, linux-nfs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-27 20:33 ` Benny Halevy
@ 2011-04-27 21:05 ` Steve Dickson
0 siblings, 0 replies; 11+ messages in thread
From: Steve Dickson @ 2011-04-27 21:05 UTC (permalink / raw)
To: Benny Halevy; +Cc: Trond Myklebust, Chuck Lever, linux-nfs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up
2011-04-22 8:46 [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up Benny Halevy
2011-04-25 14:11 ` Chuck Lever
@ 2011-05-23 12:39 ` Steve Dickson
1 sibling, 0 replies; 11+ messages in thread
From: Steve Dickson @ 2011-05-23 12:39 UTC (permalink / raw)
To: Benny Halevy; +Cc: linux-nfs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-05-23 12:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-22 8:46 [PATCH] nfsstat: reorder nfs4 stats for 2.6.38 and up Benny Halevy
2011-04-25 14:11 ` Chuck Lever
2011-04-27 4:50 ` Benny Halevy
2011-04-27 14:16 ` Trond Myklebust
2011-04-27 18:52 ` Benny Halevy
2011-04-27 18:58 ` Trond Myklebust
2011-04-27 20:24 ` Benny Halevy
2011-04-27 20:29 ` Trond Myklebust
[not found] ` <1303936194.28589.2.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
2011-04-27 20:33 ` Benny Halevy
2011-04-27 21:05 ` Steve Dickson
2011-05-23 12:39 ` Steve Dickson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.