samba - Jun 2015 - File copy operation blocks on Samba share

Hello,

I am running a server with cifs-utils 6.0 on Ubuntu 14.04 trusty with a CIFS
mount as follows:
//server/share /mnt/Share cifs
rw,relatime,vers=1.0,cache=strict,username=myuser,domain=EXAMPLE,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.0.8,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1
0 0

I am using perl's File::Copy function to copy several hundred files from the
share to the local ext4 filesystem:
cp($src, $dst, 32128);

This works fine for almost all of the files, however the perl script always
blocks in uninterruptable sleep on one file in particular. If I strace it, I see
this result:

open("/mnt/Share/file.odt", O_RDONLY) = 7
ioctl(7, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fff3cdd9f20) = -1
ENOTTY (Inappropriate ioctl for device)
lseek(7, 0, SEEK_CUR)                   = 0
fstat(7, {st_mode=S_IFREG|0644, st_size=131018, ...}) = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
open("/usr/local/share/dest.odt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 8
ioctl(8, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fff3cdd9f20) = -1
ENOTTY (Inappropriate ioctl for device)
lseek(8, 0, SEEK_CUR)                   = 0
fstat(8, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
read(7,

Thus it appears to be blocking on the read(2) command. If I kill this strace, 
the process then "wakes up" and continues processing. It seems that
inspecting
the process causes it to return from its blocking I/O. This behavior is 
reproducible on this one same file (one out of hundreds) from perl, however 
running "cp" or "md5sum" from the command line always
returns instantly on
said file.

It is worth noting that perl's File::Copy function uses 2MB sized buffers
when
calling read(2); this does not appear to work over CIFS - it returns an
Input/Output Error. However I have compensated for this by tuning the buffer
size to 32k (as noted above). Could this issue be related (or is this expected
behavior)?

Do you have any ideas what is causing this behavior, or what is causing this
read(2) to block?

Thanks,

Andrew Martin

On Tue, Jun 09, 2015 at 10:40:18AM -0500, Andrew Martin
wrote:
> Hello,
> 
> I am running a server with cifs-utils 6.0 on Ubuntu 14.04 trusty with a
CIFS
> mount as follows:
> //server/share /mnt/Share cifs
>
rw,relatime,vers=1.0,cache=strict,username=myuser,domain=EXAMPLE,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.0.8,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1
> 0 0
> 
> I am using perl's File::Copy function to copy several hundred files
from the
> share to the local ext4 filesystem:
> cp($src, $dst, 32128);
> 
> This works fine for almost all of the files, however the perl script always
> blocks in uninterruptable sleep on one file in particular. If I strace it,
I see
> this result:
> 
> open("/mnt/Share/file.odt", O_RDONLY) = 7
> ioctl(7, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fff3cdd9f20) = -1
> ENOTTY (Inappropriate ioctl for device)
> lseek(7, 0, SEEK_CUR)                   = 0
> fstat(7, {st_mode=S_IFREG|0644, st_size=131018, ...}) = 0
> fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
> open("/usr/local/share/dest.odt", O_WRONLY|O_CREAT|O_TRUNC, 0666)
= 8
> ioctl(8, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fff3cdd9f20) = -1
> ENOTTY (Inappropriate ioctl for device)
> lseek(8, 0, SEEK_CUR)                   = 0
> fstat(8, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
> read(7,
> 
> Thus it appears to be blocking on the read(2) command. If I kill this
strace,
> the process then "wakes up" and continues processing. It seems
that inspecting
> the process causes it to return from its blocking I/O. This behavior is 
> reproducible on this one same file (one out of hundreds) from perl, however
> running "cp" or "md5sum" from the command line always
returns instantly on
> said file.
> 
> It is worth noting that perl's File::Copy function uses 2MB sized
buffers when
> calling read(2); this does not appear to work over CIFS - it returns an
> Input/Output Error. However I have compensated for this by tuning the
buffer
> size to 32k (as noted above). Could this issue be related (or is this
expected
> behavior)?
> 
> Do you have any ideas what is causing this behavior, or what is causing
this
> read(2) to block?
Looks like a client bug IMHO.

----- Original Message -----
> From: "Jeremy Allison" <jra at samba.org>
> To: "Andrew Martin" <amartin at xes-inc.com>
> Cc: samba at lists.samba.org
> Sent: Wednesday, June 10, 2015 1:55:26 PM
> Subject: Re: [Samba] File copy operation blocks on Samba share
> > Do you have any ideas what is causing this behavior, or what is
causing
> > this
> > read(2) to block?
> 
> Looks like a client bug IMHO.
> 
Yes, but isn't mount.cifs (the client) part of the Samba package?

Hello Andrew,

Just curious,
how about trying to revise the mount option rsize=4096,
thank you.

--
Regards,
Jones Syue | ???
QNAP Systems, Inc.

On Tue, Jun 9, 2015 at 11:40 PM, Andrew Martin <amartin at xes-inc.com>
wrote:
> I am running a server with cifs-utils 6.0 on Ubuntu 14.04 trusty with a
> CIFS
> mount as follows:
> //server/share /mnt/Share cifs
>
>
rw,relatime,vers=1.0,cache=strict,username=myuser,domain=EXAMPLE,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.0.8,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1
> 0 0
>

Hmm perhaps also try the wsize=4096.

--
Regards,
Jones Syue | ???
QNAP Systems, Inc.

On Sat, Jun 13, 2015 at 10:19 AM, Jones Syue <jonessyue at qnap.com>
wrote:
> how about trying to revise the mount option rsize=4096,
>
>