A Question about the 2.4.21 Pathconf patch

A Question about the 2.4.21 Pathconf patch

[Steve Dickson]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: A Question about the 2.4.21 Pathconf patch

[Trond Myklebust]

>>>>> " " == Steve Dickson <SteveD@RedHat.com> 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: A Question about the 2.4.21 Pathconf patch

[Steve Dickson]

Hello Trond,

Trond Myklebust wrote:

>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....

>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.
>
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: A Question about the 2.4.21 Pathconf patch

[Trond Myklebust]

>>>>> " " == Steve Dickson <SteveD@redhat.com> 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: A Question about the 2.4.21 Pathconf patch

[Steve Dickson]

Trond Myklebust wrote:

>     > 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: A Question about the 2.4.21 Pathconf patch

[Trond Myklebust]

>>>>> " " == Steve Dickson <SteveD@redhat.com> 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: A Question about the 2.4.21 Pathconf patch

[Steve Dickson]

Trond Myklebust wrote:

>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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: A Question about the 2.4.21 Pathconf patch

[Trond Myklebust]

>>>>> " " == Steve Dickson <SteveD@redhat.com> 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs