This reconnect discussion should probably be broadened to see how it would change (the retry/timeout/reconnect) when we are tied into the (samba, user space) Witness protocol client that Guenther and others have been experimenting with. Perhaps ioctls down to cifs.ko from the witness protocol client can help us in failover more rapidly. Similarly if we can try different reconnect strategies (if this share is a dfs referral then we may already have replicas we can quickly connect to).
See http://www.sambaxp.org/archive_data/SambaXP2015-SLIDES/wed/track1/sambaxp2015-wed-track1-Guenther_Deschner-ImplementingTheWitnessProtocolInSamba.pdf for some early description of Guenther's work. On Tue, Oct 20, 2015 at 12:21 PM, Steve French <smfre...@gmail.com> wrote: > On Tue, Oct 20, 2015 at 3:20 AM, Sachin Prabhu <spra...@redhat.com> wrote: >> Hello Steve/linux-cifs, >> >> We have received a request to make the timeout in the cifs module >> tunable. >> >> I have gone through the code to understand timeouts in the cifs client. >> http://sprabhu.blogspot.in/2015/08/investigation-into-effects-of-server >> .html >> >> The way to allow user settable timeout values is to make the value of >> SMB_ECHO_INTERVAL tunable. Do you think this is a good idea? > > Seems like a reasonable idea - although we might want to treat this > differently for the case (longer timeouts? or different retry > behavior?) for the case of CA shares (or mounts with persistent handle > or resilient handle mount parms - the patches that I sent out a few > weeks ago). We also need to clean up reconnect behavior (byte range > lock recovery) and make sure for the persistent handle case (and > presumably resilient handles too) that we reopen all files on the > mount on reconnect. > > > > -- > Thanks, > > Steve -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
