How to avoid client timeout.(SMB2 ECHO Request)

sandeep nag sandeepnagamalli at gmail.com
Fri Feb 7 05:01:21 MST 2014


Thank you Jones.

We have already done this work around(at windows client regedit) for now,
to one of our customer. But looking for a solution that can be done at the
samba server/plugin to keep it clean.
Please can you tell me the functions/code that I have to see understand the
echo, reply code paths.


Thanks,
Sandeep.


On Fri, Feb 7, 2014 at 3:28 AM, Jones <jones.kstw at gmail.com> wrote:

> Hello Sandeep,
>
> Just interesting,
> if the client is windows-based OS, like Windows 7,
> try to edit regedit to increase the SessTimeout value,
> this workaround might ease the pain about this timeout issue.
>
> My test environment set "strict allocate = yes",
> uploading 20GB file and got this timeout issue,
> windows client would prompt "Retry?" after 60sec.
>
> It is likely if disk I/O is involved during allocation,
> the response time takes more and longer latency.
> And windows client thought it is timeout and re-negotiation.
>
> After create this dword to with 120 value and reboot client,
> it is okay to uploading 20GB file,
> though the "Calculating..." remains for a while.
>
> With wshark timestamp show that after setinfo request send out,
> samba takes 102 seconds to send back setinfo response,
> as Richard mentioned, how long it takes might also depend on back-end
> capability.
>
> I've tried "async smb echo handler = yes",
> but still with no luck.
>
> Hope this regedit would help.
>
> Path:
>  \HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\
> Name: SessTimeout
> Type: DWORD
> Value: 120 (unit is second)
>
> Reference:
>
> http://blogs.msdn.com/b/openspecification/archive/2013/03/27/smb-2-x-and-smb-3-0-timeouts-in-windows.aspx
>
>
> --
> Jones
>
>
> 2014-02-07 sandeep nag <sandeepnagamalli at gmail.com>:
>
> @Richard: Thank you, for the reply.
>>
>> Yes, sometimes in cases where box is in space-out situation, back-end
>> write/truncate does take more that 60 sec in our back-end.
>> Now in such scenarios where back-end is taking long time  > 60 sec, can we
>> keep the samba connection alive by responding to Echo SMB2/CIFS client
>> packets.
>> Can we do this in VFS plugin reply function such as
>> ocafs_ocafs_reply_commom().
>>
>>
>> On Thu, Feb 6, 2014 at 10:41 PM, Richard Sharpe <
>> realrichardsharpe at gmail.com
>> > wrote:
>>
>> > On Thu, Feb 6, 2014 at 10:00 PM, sandeep nag <
>> sandeepnagamalli at gmail.com>
>> > wrote:
>> > > http://msdn.microsoft.com/en-us/library/cc246540.aspx
>> > >
>> > > There is write/truncate request from the client and processing in
>> samba
>> > VFS
>> > > plugin is taking longer time(which is expected as per our VFS plugin
>> > > processing time).
>> > > The client meanwhile sends many SMB ECHO requests
>> > > (every 30 seconds (not sure)). However, they sit in the socket because
>> > the
>> > > smbd
>> > > is now stuck and will only process the ECHOs after the truncate.
>> Because
>> > > of this, I am seeing client time outs.
>> > >
>> > > If the ECHO could be responded promptly, then the client would not
>> time.
>> > > How can this be done, please guide me in
>> implementing/coding/undertanding
>> > > this.
>> >
>> > Only you know the details of your back-end ... and I thought that it
>> > did write-behind.
>> >
>> > In any event, if your back end is taking more than sixty seconds for a
>> > write that is a problem, isn't it.
>> >
>> > Maybe you should ask Tarun.
>> >
>> > --
>> > Regards,
>> > Richard Sharpe
>> > (何以解憂?唯有杜康。--曹操)
>> >
>>
>
>
>
> --
> Jones
>


More information about the samba-technical mailing list