> The Linux client is asking for SMB1 and using 1MB write sizes. > > The Windows client is using SMB2 and *NOT ASKING FOR LEASES*. > > This is why the performance is terrible. Because the file > as no lease, the Windows redirector must pass every single > WriteFile() system call onto the wire, no matter how small > the size. > > If you can get the Windows SMB2 client to request a lease, > the performance problem will be solved.Jeremy, Thanks for the response that's definitely more information than I've been able to find over the past year!> What is your server ? Is it Samba ? If so what version ?My NAS is a Synology DS215j and it is running Samba. smbd -V gives me the following: Version 4.4.13 Synology Build 15152, Jul 13 2017 04:48:37 So, this morning I ran a test by enabling leases, which were not enabled on the server before. So, now my smb.conf looks like this: [global] printcap name=cups winbind enum groups=yes include=/var/tmp/nginx/smb.netbios.aliases.conf min protocol=NT1 socket options=TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536 security=user local master=no realm=* use sendfile=yes min receivefile size=16384 passdb backend=smbpasswd write cache size=2097152 smb2 leases=yes printing=cups max protocol=SMB3 winbind enum users=yes getwd cache=true load printers=yes workgroup=WORKGROUP I noticed now that the packet capture shows Negotiate Protocol Response conversations between the server and the Windows client. It also seems the client is now using a lease. Unfortunately, the Windows client is still immediately writing one line at a time :( I have uploaded the new packet capture snippet here (2MB): https://drive.google.com/open?id=0B6UHr3GQEkQwcXdEWVRFSXRMNnc Hopefully, I'm getting closer? :) Does the smb.conf looks reasonable to you? Thanks again for all your help, it's greatly appreciated! Will On Fri, Oct 6, 2017 at 7:09 PM Jeremy Allison <jra at samba.org> wrote:> On Fri, Oct 06, 2017 at 07:26:29PM +0000, Will Lucas wrote: > > > > Does the wireshark trace show the Windows client asking for and > > getting a RWH lease under SMB2 ? If so, then there's no reason > > it can't be caching the entire file locally. Seems strange > > behaviour from the Windows redirector here. > > > > > > I have uploaded the Linux packet capture here (14MB): > https://drive.google.com/ > > open?id=0B6UHr3GQEkQwWXJ1NjVwMkJXOEU > > > > Also, here is the corresponding Windows packet capture as well > (375MB): https:/ > > /drive.google.com/open?id=0B6UHr3GQEkQwbFhOY0lCcEFjZkU > > to Windows :-). > > The Linux client is asking for SMB1 and using 1MB write sizes. > > The Windows client is using SMB2 and *NOT ASKING FOR LEASES*. > > This is why the performance is terrible. Because the file > as no lease, the Windows redirector must pass every single > WriteFile() system call onto the wire, no matter how small > the size. > > If you can get the Windows SMB2 client to request a lease, > the performance problem will be solved. > > What is your server ? Is it Samba ? If so what version ? >
On Mon, Oct 09, 2017 at 08:29:43PM +0000, Will Lucas wrote:> > The Linux client is asking for SMB1 and using 1MB write sizes. > > > > The Windows client is using SMB2 and *NOT ASKING FOR LEASES*. > > > > This is why the performance is terrible. Because the file > > as no lease, the Windows redirector must pass every single > > WriteFile() system call onto the wire, no matter how small > > the size. > > > > If you can get the Windows SMB2 client to request a lease, > > the performance problem will be solved. > > Jeremy, > > Thanks for the response that's definitely more information than I've been able > to find over the past year! > > > What is your server ? Is it Samba ? If so what version ? > > My NAS is a Synology DS215j and it is running Samba. smbd -V gives me the > following: > Version 4.4.13 > Synology Build 15152, Jul 13 2017 04:48:37 > > So, this morning I ran a test by enabling leases, which were not enabled on the > server before. So, now my smb.conf looks like this: > [global] > printcap name=cups > winbind enum groups=yes > include=/var/tmp/nginx/smb.netbios.aliases.conf > min protocol=NT1 > socket options=TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536 > security=user > local master=no > realm=* > use sendfile=yes > min receivefile size=16384 > passdb backend=smbpasswd > write cache size=2097152 > smb2 leases=yes > printing=cups > max protocol=SMB3 > winbind enum users=yes > getwd cache=true > load printers=yes > workgroup=WORKGROUP > > I noticed now that the packet capture shows Negotiate Protocol Response > conversations between the server and the Windows client. It also seems the > client is now using a lease. Unfortunately, the Windows client is still > immediately writing one line at a time :( > > I have uploaded the new packet capture snippet here (2MB): https:// > drive.google.com/open?id=0B6UHr3GQEkQwcXdEWVRFSXRMNnc > > Hopefully, I'm getting closer? :) Does the smb.conf looks reasonable to you?So it's now getting a RWH lease, but still doing the raw syscall reads across the wire. Does it do the same to a Windows server ? Looks like the client application is deliberately turning off any redirector caching by using FILE_FLAG_WRITE_THROUGH on the CreateFile() Win32 call. If you can do the equivalent of strace on Windows (I don't know how) you might be able to confirm that and ask the app developer to stop doing that. https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx FILE_FLAG_WRITE_THROUGH 0x80000000 Write operations will not go through any intermediate cache, they will go directly to disk. For additional information, see the Caching Behavior section of this topic.
> So it's now getting a RWH lease, but still doing the raw > syscall reads across the wire. > > Does it do the same to a Windows server ? Looks like the > client application is deliberately turning off any > redirector caching by using FILE_FLAG_WRITE_THROUGH on > the CreateFile() Win32 call. If you can do the equivalent > of strace on Windows (I don't know how) you might be > able to confirm that and ask the app developer to stop > doing that. > >https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx> > > FILE_FLAG_WRITE_THROUGH > 0x80000000 > > > > Write operations will not go through any intermediate cache, they will godirectly to disk.> > For additional information, see the Caching Behavior section of thistopic. Jeremy, It turns out the program was definitely flushing the stream after every write (I verified this was the case with ProcMon), but I couldn't figure out why (as I wasn't specifying the flush explicitly). I also tried NFS on Windows and it behaved exactly the same way. I was completely stumped until someone pointed out that endl flushes the stream implicitly. Now SMB is buffering properly! Your help was definitely instrumental in me finding the ultimate cause, so thank you very much! Will