On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote: > On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote: > > Also, while I hope this is the last bug in the mountd's flavor list > > return, it isn't the first--only recently did we even start using real > > information from the export instead of just faking something up. So I > > think it's safest to preserve the historical sec= behavior and give > > users a way to override the negotiation, to cut down on bug reports of > > mount failures on upgrade. > > OK, if this is a recently introduced server problem, then why do we > need to adjust client-side behavior? Trond's response in cases like > this is usually "fix the d*mn server," which you've already done. What is the definition of "recently introduced" here? What is the exact commit that introduced the bug in nfs-utils? The problem is that we're changing the client, and if it turns out that every damned Linux server that was installed out there in the past 2 years displays this bug, then Linus will call 'regression' on us and revert the code. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
