* [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
[parent not found: <1303936194.28589.2.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>]
* 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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).