Hi,
There seem to be legitimate reasons for an (NFSv4.1) client and/or server to prefer a dedicated callback channel.
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.
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.
Thanks,
Matt
--
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSaWNrIE1hY2tsZW0gW21haWx0
bzpybWFja2xlbUB1b2d1ZWxwaC5jYV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDYsIDIw
MTEgOTo0MiBQTQ0KPiBUbzogTXlrbGVidXN0LCBUcm9uZA0KPiBDYzogbGludXgtbmZzOyBuZnMt
Z2FuZXNoYS1kZXZlbDsgbmZzdjQ7IE1hdHQgVy4gQmVuamFtaW4NCj4gU3ViamVjdDogUmU6IFtu
ZnN2NF0gYmFjayBjaGFubmVsIGZsYWdzLCBDUkVBVEVfU0VTU0lPTiwNCj4gQklORF9DT05OX1RP
X1NFU1NJT04NCj4gDQo+IFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4gPiBPbiBXZWQsIDIwMTEt
MTAtMDUgYXQgMTk6MjEgLTA0MDAsIE1hdHQgVy4gQmVuamFtaW4gd3JvdGU6DQo+IEp1c3QgZnlp
LCB3aGF0IEkgaGF2ZSBpbXBsZW1lbnRlZCAoYW5kIEkgZG9uJ3QgaW50ZW5kIHRvIGNoYW5nZSBp
dCkgaXMgd2hhdA0KPiBUcm9uZCBjdXJyZW50bHkgaGFzIGRvbmUuIEZvciB0aGUgRnJlZUJTRCA0
LjEgY2xpZW50LCBpdCB3aWxsIHNldA0KPiBDUkVBVEVfU0VTU0lPTjRfRkxBR19DT05OX0JBQ0tf
Q0hBTiBpbiBjc2FfZmxhZ3MsIGJ1dCBpZiB0aGUgc2VydmVyDQo+IGRvZXNuYHQgc2V0IGl0IGlu
IGNzcl9mbGFncywgSSBzaW1wbHkgYXNzdW1lIGBubyBiYWNrY2hhbm5lbGAuIEkgZG9uYHQgcGxh
biBvbg0KPiBpbXBsZW1lbnRpbmcgYSBkZWRpY2F0ZWQgYmFjayBjaGFubmVsLiAoSSBzdXBwb3Nl
IHRoYXQgY291bGQgY2hhbmdlIGlmDQo+IHRoZXJlIHdlcmUgc3Ryb25nIGV2aWRlbmNlIHRoYXQg
YSBkZWRpY2F0ZWQgYmFjayBjaGFubmVsIGRpZCBpbXByb3ZlDQo+IHBlcmZvcm1hbmNlIHNpZ25p
ZmljYW50bHkuKQ0KPiANCj4gSSB0aG91Z2h0IElgZCBwb3N0IHRoaXMgbWFpbmx5IHRvIHNob3cg
dGhhdCB0aGVyZSBhcmUgYWN0dWFsbHkgdGltZXMgd2hlbiBJDQo+IGFncmVlIHdpdGggVHJvbmQ7
LSkgcmljaw0KDQpIZXkuLi4gRG9uJ3QgeW91IGFsd2F5cz8gOy0pDQoNCiAgICAgVHJvbmQNCg==
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
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?
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Wed, 2011-10-05 at 23:28 -0400, Trond Myklebust wrote:
> On Wed, 2011-10-05 at 19:21 -0400, Matt W. Benjamin wrote:
> > 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?
To put it in more basic terms: what you are proposing will add
development costs to the client and and an extra code burden to maintain
long term. So what is in it for me?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com