Hi Trond, > 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. For whom? Well, I work primarily on servers. I have worked experimentally on the Linux v41 client. I am pretty sure I wasn't speaking of a "callback scalability breakdown." I was discussing a tradeoff of ports for reduced overhead of flow control, lock contention, etc. I wasn't trying to start an inflated theory discussion about these, I don't feel fully at ease doing so. Still, I don't intuit that potential for port exhaustion trumps other considerations, it is one consideration among several. I also mentioned some potential benefit for server implementations, such as the one we have been collaborating on. I'd like to maximize its potential for success. ----- "Trond Myklebust" <Trond.Myklebust@xxxxxxxxxx> wrote: > > 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.) You think the standard should influence, so as to reduce, the number of competing implementations? Maybe you meant 'implementation choices for <x> feature.' My expectation from NFSv4 is that there is some room for innovation and experimentation. I don't think we can avoid this if we wish to compete effectively with ad hoc storage protocols. > > 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. I find I need to keep reminding my self what "assume" does. But I assumed that the 5661 language for negotiating a back channel was in the draft (standard) because it added value to someone, and perhaps was implemented in some environment. If so, perhaps such a person will chime in with an opinion. > > Trond 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 -- 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
