Access samba share which underlying storage is very slow

Access samba share which underlying storage is very slow

[Wang, Zhiye]

Dear all,

I use Samba to share FUSE based file system which underlying storage is very slow sometimes (not always). Read/Write/Open sometimes may take several minutes. And especially, "write" must be in sequential manner. And "write to file" cannot break in the middle of a file (much like tape).

All that are ok for Samba, but it seems to be a problem for CIFS on client side. It seems operations timeout are all hardcoded, and cannot be adjusted during mount. After timeout, CIFS client will reconnect and then resume "write" from where is broken (but this is not acceptable for my case).

Is there a way to make CIFS client block at slow operations without timeout?


Thanks
Mike

Fwd: Access samba share which underlying storage is very slow

[Steve French]

---------- Forwarded message ----------
From: Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, Dec 13, 2016 at 11:20 AM
Subject: Re: Access samba share which underlying storage is very slow
To: "Wang, Zhiye" <Zhiye.Wang-gYDOmNCWHYlWk0Htik3J/w@public.gmane.org>
Cc: "linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>


there is a "hard" mount option and the "echo" timeout can be adjusted on mount

On Tue, Dec 13, 2016 at 7:35 AM, Wang, Zhiye <Zhiye.Wang-gYDOmNCWHYlWk0Htik3J/w@public.gmane.org> wrote:
>
> Dear all,
>
> I use Samba to share FUSE based file system which underlying storage is very slow sometimes (not always). Read/Write/Open sometimes may take several minutes. And especially, "write" must be in sequential manner. And "write to file" cannot break in the middle of a file (much like tape).
>
> All that are ok for Samba, but it seems to be a problem for CIFS on client side. It seems operations timeout are all hardcoded, and cannot be adjusted during mount. After timeout, CIFS client will reconnect and then resume "write" from where is broken (but this is not acceptable for my case).
>
> Is there a way to make CIFS client block at slow operations without timeout?
>
>
> Thanks
> Mike
>
>



-- 
Thanks,

Steve



-- 
Thanks,

Steve

RE: Access samba share which underlying storage is very slow

[Wang, Zhiye]

Thank you for the information.

"hard" seems a good option for me. I will do more test.

As to "echo" timeout, are you referring "echo_interval"? It seems this option was implemented pretty late, and only most recent Linux distributions include its support.

Besides that, I have already configured samba server to serve "echo" request in separated process("async smb echo handler = yes", so "echo" server will not be blocked by "open/read/write" operations), but I can still see warning below on client side:

[620422.570128] CIFS VFS: Server 10.57.33.134 has not responded in 120 seconds. Reconnecting...


Do you have any suggestion on this?


Thanks
Mike





发件人: Steve French <smfrench@gmail.com>
发送时间: 2016年12月14日 1:20
收件人: Wang, Zhiye
抄送: linux-cifs@vger.kernel.org
主题: Re: Access samba share which underlying storage is very slow
  

there is a "hard" mount option and the "echo" timeout can be adjusted on mount


On Tue, Dec 13, 2016 at 7:35 AM, Wang, Zhiye  <Zhiye.Wang@arcserve.com> wrote:
 Dear all,

I use Samba to share FUSE based file system which underlying storage is very slow sometimes (not always). Read/Write/Open sometimes may take several minutes. And especially, "write" must be in sequential manner. And "write to file" cannot break in the middle  of a file (much like tape).

All that are ok for Samba, but it seems to be a problem for CIFS on client side. It seems operations timeout are all hardcoded, and cannot be adjusted during mount. After timeout, CIFS client will reconnect and then resume "write" from where is broken (but  this is not acceptable for my case).

Is there a way to make CIFS client block at slow operations without timeout?


Thanks
Mike


 



 -- 

Thanks,

Steve     

Re: Access samba share which underlying storage is very slow

[Steve French]

Yes - you are probably correct since echo_interval tunable was added
in the last year or so.

Reconnection logic has been much improved over the past three years,
so make sure you are not running a very old kernel (or ask your distro
to backport fixes) - there are lots of corner cases in reconnect.

Note that very old cifs had an "echo retries" module load parm (for
cifs.ko) that could be increased from its default of 5 (or reconnect
could be disabled by setting to zero).   The echo interval was 60
seconds.

Note that even this far back cifs.ko intentionally did not timeout on
certain (potentially very slow) operations (writes that are past end
of file was one example)


On Wed, Dec 14, 2016 at 8:05 AM, Wang, Zhiye <Zhiye.Wang-gYDOmNCWHYlWk0Htik3J/w@public.gmane.org> wrote:
> Thank you for the information.
>
> "hard" seems a good option for me. I will do more test.
>
> As to "echo" timeout, are you referring "echo_interval"? It seems this option was implemented pretty late, and only most recent Linux distributions include its support.
>
> Besides that, I have already configured samba server to serve "echo" request in separated process("async smb echo handler = yes", so "echo" server will not be blocked by "open/read/write" operations), but I can still see warning below on client side:
>
> [620422.570128] CIFS VFS: Server 10.57.33.134 has not responded in 120 seconds. Reconnecting...
>
>
> Do you have any suggestion on this?
>
>
> Thanks
> Mike
>
>
>
>
>
> 发件人: Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 发送时间: 2016年12月14日 1:20
> 收件人: Wang, Zhiye
> 抄送: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 主题: Re: Access samba share which underlying storage is very slow
>
>
> there is a "hard" mount option and the "echo" timeout can be adjusted on mount
>
>
> On Tue, Dec 13, 2016 at 7:35 AM, Wang, Zhiye  <Zhiye.Wang-gYDOmNCWHYlWk0Htik3J/w@public.gmane.org> wrote:
>  Dear all,
>
> I use Samba to share FUSE based file system which underlying storage is very slow sometimes (not always). Read/Write/Open sometimes may take several minutes. And especially, "write" must be in sequential manner. And "write to file" cannot break in the middle  of a file (much like tape).
>
> All that are ok for Samba, but it seems to be a problem for CIFS on client side. It seems operations timeout are all hardcoded, and cannot be adjusted during mount. After timeout, CIFS client will reconnect and then resume "write" from where is broken (but  this is not acceptable for my case).
>
> Is there a way to make CIFS client block at slow operations without timeout?
>
>
> Thanks
> Mike
>
>
>
>
>
>
>  --
>
> Thanks,
>
> Steve



-- 
Thanks,

Steve

RE: Access samba share which underlying storage is very slow

[Wang, Zhiye]

Thank you for the suggestions.


-----Original Message-----
From: Steve French [mailto:smfrench@gmail.com] 
Sent: Thursday, December 15, 2016 7:28 AM
To: Wang, Zhiye <Zhiye.Wang@Arcserve.com>
Cc: linux-cifs@vger.kernel.org
Subject: Re: Access samba share which underlying storage is very slow

Yes - you are probably correct since echo_interval tunable was added in the last year or so.

Reconnection logic has been much improved over the past three years, so make sure you are not running a very old kernel (or ask your distro to backport fixes) - there are lots of corner cases in reconnect.

Note that very old cifs had an "echo retries" module load parm (for
cifs.ko) that could be increased from its default of 5 (or reconnect
could be disabled by setting to zero).   The echo interval was 60
seconds.

Note that even this far back cifs.ko intentionally did not timeout on certain (potentially very slow) operations (writes that are past end of file was one example)


On Wed, Dec 14, 2016 at 8:05 AM, Wang, Zhiye <Zhiye.Wang@arcserve.com> wrote:
> Thank you for the information.
>
> "hard" seems a good option for me. I will do more test.
>
> As to "echo" timeout, are you referring "echo_interval"? It seems this option was implemented pretty late, and only most recent Linux distributions include its support.
>
> Besides that, I have already configured samba server to serve "echo" request in separated process("async smb echo handler = yes", so "echo" server will not be blocked by "open/read/write" operations), but I can still see warning below on client side:
>
> [620422.570128] CIFS VFS: Server 10.57.33.134 has not responded in 120 seconds. Reconnecting...
>
>
> Do you have any suggestion on this?
>
>
> Thanks
> Mike
>
>
>
>
>
> 发件人: Steve French <smfrench@gmail.com>
> 发送时间: 2016年12月14日 1:20
> 收件人: Wang, Zhiye
> 抄送: linux-cifs@vger.kernel.org
> 主题: Re: Access samba share which underlying storage is very slow
>
>
> there is a "hard" mount option and the "echo" timeout can be adjusted 
> on mount
>
>
> On Tue, Dec 13, 2016 at 7:35 AM, Wang, Zhiye  <Zhiye.Wang@arcserve.com> wrote:
>  Dear all,
>
> I use Samba to share FUSE based file system which underlying storage is very slow sometimes (not always). Read/Write/Open sometimes may take several minutes. And especially, "write" must be in sequential manner. And "write to file" cannot break in the middle  of a file (much like tape).
>
> All that are ok for Samba, but it seems to be a problem for CIFS on client side. It seems operations timeout are all hardcoded, and cannot be adjusted during mount. After timeout, CIFS client will reconnect and then resume "write" from where is broken (but  this is not acceptable for my case).
>
> Is there a way to make CIFS client block at slow operations without timeout?
>
>
> Thanks
> Mike
>
>
>
>
>
>
>  --
>
> Thanks,
>
> Steve



--
Thanks,

Steve