A Question about the 2.4.21 Pathconf patch
Subsystems (2)
I noticed in the Trond's linux-2.4.21-08-pathconf.dif patch that nfs_proc_fsinfo uses the NFSPROC_STATFS instead of (what I would expect) the NFSPROC_FSINFO procedure as defined in the v3 spec. Now I realize that fsinfo is not support in v2 but doesn't it make sense to use it with v3 or am I missing something here. I would think that if the server sent some numbers that the client couldn't handle, the client would simple fail the mount...
Has anybody tried using NFSPROC_FSINFO instead of NFSPROC_STATFS?
SteveD
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Steve Dickson <[email protected]> writes:
> but doesn't it make sense to use it with v3 or am I missing > something here. I would think that if the server sent some > numbers that the client couldn't handle,
> the client would simple fail the mount...
Why would we want to succeed in that case? If the server operates with some screwed up set of parameters that we are incapable of supporting, surely the best thing to do is to fail immediately?
Note: Most of the functionality of NFSPROC3_FSINFO *is* in fact in v2, but it is either part of NFSPROC_STATFS, or (shudder) has been tacked onto the mount protocol.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hello Trond,
Quoted 4 lines · Trond Myklebust
Why would we want to succeed in that case? If the server operates with some screwed up set of parameters that we are incapable of supporting, surely the best thing to do is to fail immediately?
Very true... I think we are saying the same thing.... Maybe I was not too clear....
Quoted 4 lines
Note: Most of the functionality of
NFSPROC3_FSINFO*is* in fact in v2, but it is either part ofNFSPROC_STATFS, or (shudder) has been tacked onto the mount protocol.
Right... but with the difference being that statfs supplies dynamic information and fsinfo supplies static info. And some the fsinfo info, like readdir sizes, procedures not supported, max reads/writes sizes along with preferred read/write sizes seems like good information to have about the server, although not totally necessary, obviously ;-)
So I'm just curious, why (from a protocol purest standpoint) its not being used... and if it ever was used, what were the results...
SteveD.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Steve Dickson <[email protected]> writes:
> Right... but with the difference being that statfs supplies > dynamic information and fsinfo supplies static info. And some
NFSPROC_STATFS supplies a bit of both. You have the dynamic 'blocks, bfree, bavail', but you also have the static 'tsize' == r/wsize, and 'bsize'.
> So I'm just curious, why (from a protocol purest standpoint) > its not being used... and if it ever was used, what were the > results...
I'm not sure I understand the question. In which case do you think we should be using FSINFO/STATFS (but are currently not doing so)?
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Steve Dickson <[email protected]> writes:
> So I'm just curious, why (from a protocol purest standpoint) > its not being used... and if it ever was used, what were the > results...
Oh... Are you perhaps thinking of the RedHat kernels, which contain a patch to disable the FSINFO usage? That's Ben LaHaise's decision.
Earlier 2.4.x kernels had a bug in the IPv4 socket layer (in ip_build_xmit_slow() to be more precise). When using non-blocking writes, the socket layer would build incomplete sets of fragments, then quit with an -EAGAIN. This had a disastrous DOS effect on certain servers which weren't able to cope with the flood of orphaned fragments.
Instead of waiting for the fix, Ben therefore decided to turn off the automatic probing of r/wsize, and just make the default 4k.
This patch is not in the standard kernel, since we have a proper fix for the real problem.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 7 lines · Trond Myklebust
Quoted 3 lines
So I'm just curious, why (from a protocol purest standpoint) its not being used... and if it ever was used, what were the results...
I'm not sure I understand the question. In which case do you think we should be using FSINFO/STATFS (but are currently not doing so)?
In the linux-2.4.21-08-pathconf.dif patch, nfs_proc_fsinfo() does a rpc_call(NFSPROC_STATFS) call and then fill in the nfs_fsinfo structure with constants and values returned in the nfs2_statfs structure.
I'm just wondering why nfs_proc_fsinfo() doesn't do a rpc_call(NFSPROC_FSINFO) which would fill the nfs_fsinfo structure with the values from the server. Of course these values would have to be check for sanity... I just seems to me that would be good information to to have on hand...
SteveD.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Steve Dickson <[email protected]> writes:
> rpc_call(NFSPROC_FSINFO) which would fill the nfs_fsinfo > structure with the values from the server. Of course these > values would have to be check for sanity... I just seems to me > that would be good information to to have on hand...
It does the RPC call at mount time instead, then caches the results.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 2 lines · Trond Myklebust
It does the RPC call at mount time instead, then caches the results.
Aha.... I see.... nfs3_proc_fsinfo() does the fsinfo and nfs_proc_fsinfo() is the v2 version (i.e. uses statfs).... I missed that!!! I guess the naming got me confused and I didn't expect v2 to even support the notion of fsinfo.... It makes sense now... Thanks for straighting that for me.....
SteveD.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs