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 <[email protected]>
---
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
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 <[email protected]> ---
>> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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
[email protected]
http://www.netapp.com
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
[email protected]
http://www.netapp.com
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
[email protected]
http://www.netapp.com
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
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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
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.
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?
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
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 <[email protected]>
> ---
> 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.