On Wed, Dec 16, 2015 at 10:37 PM, Steve French <smfrench@xxxxxxxxx> wrote: > Why restrict the echo interval to such a narrow range? If tunable > might as well allow a larger range, maybe 1 to 600 (ten minutes)? I > am not certain of the range of possible future uses - maybe a > pseudo-real type workload connected to a really fast server wants > something really low (a few seconds?) and maybe very poor network > connections want something longer? Not a strong objection, but seems > like we could allow a broader range without confusing the user. > > Many years ago, Windows and OS/2 had an oplock break time (which also > controlled how long to wait for acks to come back from the server) - > and it ranged from 34 to 127 seconds for acks and 35 to 640 for oplock > break timeouts. Don't see any reason to limit it less than that > (that was really old and networks vary a lot in performance now). > > Thoughts? For context, were those timeouts for when broadcasts and signaling were over three protocols (IPX, IP, and NetBEUI? I can't recall, but Chris H. was telling tales of yore last month at a dinner and IIRC the propagation for SMB was over three protocols because usually at least one would eventually reach remote hosts under most conditions)? I have no issue with long timeouts, but what was the historical context of the 10 minute oplock breaks? Forgive me if I'm recalling incorrectly, but I thought that the extended timeouts were for much-less-than-optimal conditions over multiple protocols attached to hubs. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
