Trond Myklebust wrote: > On Wed, 2011-10-05 at 19:21 -0400, Matt W. Benjamin wrote: > > Hi, > > > > There seem to be legitimate reasons for an (NFSv4.1) client and/or > > server to prefer a dedicated callback channel. > > That would be an assertion that is missing a lot of context and > explanation. Why should my client bother to support such a server? > > > If a server wants this result, it seems from the language of 18.36.3 > > that it should indicate it by not setting > > CREATE_SESSION4_FLAG_CONN_BACK_CHAN in csr_flags in the > > CREATE_SESSION response, presuming the flag is set in the > > corresponding csa_flags argument (it's not allowed to set it > > otherwise). The client may respond with BIND_CONN_TO_SESSION on a > > new channel, setting bctsa_dir to CDFC4_BACK. > > Nope. The exact wording is: > > If CREATE_SESSION4_FLAG_CONN_BACK_CHAN is set in csa_flags, the > client is requesting that the connection over which the > CREATE_SESSION operation arrived be associated with the > session's backchannel in addition to its fore channel. If the > server agrees, it sets CREATE_SESSION4_FLAG_CONN_BACK_CHAN in > the result field csr_flags. If > CREATE_SESSION4_FLAG_CONN_BACK_CHAN is not set in csa_flags, > then CREATE_SESSION4_FLAG_CONN_BACK_CHAN MUST NOT be set in > csr_flags. > > I see nothing there to indicate that the server is able to request a > dedicated backchannel. All it says is that the server may refuse a > backchannel on this particular connection. > > > Currently, the Linux and I believe also the CITI Windows client > > always propose channels in both directions. The Linux mainline Linux > > client doesn't know how to BIND_CONN_TO_SESSION, so trivially it > > won't negotiate any back channel if a server didn't agree to both > > directions today, either. I've experimentally implemented a > > "fallback" model in a Linux client and (partly in a) Ganesha server. > > I'd appreciate any feedback on the idea. > > Yep. As I said, why should we bother adding support for servers that > don't? I can function perfectly well without pNFS support or > delegation > support in such a case. Performance will suck, but why do I care? > Just fyi, what I have implemented (and I don't intend to change it) is what Trond currently has done. For the FreeBSD 4.1 client, it will set CREATE_SESSION4_FLAG_CONN_BACK_CHAN in csa_flags, but if the server doesn`t set it in csr_flags, I simply assume `no backchannel`. I don`t plan on implementing a dedicated back channel. (I suppose that could change if there were strong evidence that a dedicated back channel did improve performance significantly.) I thought I`d post this mainly to show that there are actually times when I agree with Trond;-) rick -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
