> -----Original Message----- > From: Matt W. Benjamin [mailto:matt@xxxxxxxxxxxx] > Sent: Thursday, October 06, 2011 11:11 AM > To: Myklebust, Trond > Cc: nfsv4; linux-nfs; nfs-ganesha-devel > Subject: Re: [nfsv4] back channel flags, CREATE_SESSION, > BIND_CONN_TO_SESSION > > Hi Trond, > > The rationale for making it possible to arrive at a dedicated back channel for a > session is, I think, mainly that it can yield greater throughput, a benefit which > grows as workload increases. Conversely, channel negotiation appears to > not have many downsides. Why do we need such a huge volume of callbacks? They should be the exception rather than the rule, since their effect is always to slow down performance. Throughput is in addition limited by the number of session slots (currently 1). > My reasoning would be mainly that the dedicated configuration appears to > minimise the throughput potentially lost to flow control or head-of-line > blocking, in particular when the the underlying transport is TCP. A slightly > different way to look at it is, that it enables a simpler RPC dispatcher at both > endpoints. (I doubt the latter is more than a short-term consideration. Still, > having an ability to work around a class of transport/interop problems > transparently, which the fallback strategy could permit, might be viewed as a > win.) For whom? We have already implemented a callback model that is working fine for us. I have yet to see any evidence of the callback scalability breakdown scenario that you claim as a motivation. What I have (frequently) seen is scalability issues due to clients and servers running out of free TCP ports. > If one is persuaded of the potential utility of a dedicated session back > channel, it still might not appear clearly better to have the client initially > propose a mixed channel and assume the server will object if it cares (as > opposed to making a dedicated fore channel its initial proposal). I think the > fallback strategy is slightly better. It offers both client and server input into > the transport setup, and it has the benefit of being closest to what 41 servers > currently do and the Linux client currently does. > > As you correctly state, the client could proceed without a back channel in the > presence of a "disagreeing" server and still be conformant with RFC 5661 (if > perhaps not in spirit), but actually, I'm not certain that the Linux client actually > does proceed as specified in this case, as presently implemented (3.1.0-rc8)-- > I think it may incorrectly assume that a mixed channel has been agreed on. I agree that we should fix that bug. I disagree that we need a second callback model to do so. Just turn off pNFS (and possibly WANTs if we ever implement them), and we should be fine. > Back channel negotiation does what it does, seemingly, at very little cost in > development (a few hundred lines, mostly structure formulas). > Maintenance costs are said to be proportional to code size (or so I have read, > e.g., Page-Jones). I'm not making light of this point, obviously everything has > a cost. My objection is to the lack of a consensus on a single system for implementing features. I'm tired of being told that the spec allows you to do the same thing in 10 different ways, with an expectation that we should implement all 10 ways. If we can't find a single good way of implementing a feature, then my preference is to drop support for that feature altogether (or to choose one implementation and to stick with it). My expectation for a standard is that it should aim to _reduce_ the number of different implementations so that we can concentrate our development and testing efforts. (BTW: pNFS is definitely not beyond criticism in this respect.) IOW: I can see valid reasons for why we should test the case where the server refuses a mixed fore+back channel, but I don't see that as a reason to implement a second back channel model. That requires us to add code + tests (and perform regular regression tests) for that back channel mode, as well as dealing with the case where that model of operation too is rejected by the server. Trond ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
