windows 2000: slow file copy from windows 2000 to SAMBA

[Ulf Bertilsson]

Could this be applied into 2.0.X as well ?

> -----Original Message-----
> From: Jeremy Allison [mailto:jeremy at valinux.com]
> Sent: Wednesday, May 23, 2001 6:58 PM
> To: Coupal, Chris ISC
> Cc: 'samba-technical at lists.samba.org'; tridge at samba.org
> Subject: Re: windows 2000: slow file copy from windows 2000 to SAMBA
> 
> 
> "Coupal, Chris ISC" wrote:
> > 
> > Greetings,
> > 
> > I have a interesting problem copying large files from a 
> Windows2000 server
> > to a SAMBA share. The copy takes extremely long. For 
> example, a 600K file
> > takes in excess of 40 seconds. Initially, we had the 
> problem copy the file
> > to NT 4 machines as well, but we fixed it with the 
> following work around
> > which explains the problem well:
> > 
> > Is there a way we can apply the same "FIX" to samba?
> 
> You, sir, are a hero ! I looked at those msdn entries...
> 
> It turns out the we didn't understand the implications of
> CAP_LARGE_READX/CAP_LARGE_WRITEX very well.
> 
> NT normally negotiates a small (4k) buffer, and so sends
> very small read/write requests. It uses raw reads/writes
> to send larger reads and writes, *BUT ONLY UP TO THE 64k
> NetBIOS FRAME SIZE* !
> 
> This is a very important thing. Samba *always* offers a
> 64k buffer size to the client, so there really is no difference
> for us between raw and normal reads/writes.
> 
> Microsoft "LARGE" read and writes have the capability
> to be 32 bit (if you look at the CIFS spec) as they
> dedicate a new 16 bit length field on top of the existing
> one. However, the NetBIOS frame size prohibits this from
> actually being used, so on the wire their "large" read/writes
> are just 0xF000 (for safety I guess). Samba can *already*
> handle reads and writes of this size as we allocate a
> 64k buffer anyway.
> 
> So..... it turns out all you need to do is apply the
> following patch (which I've just applied to the 2.2 and HEAD
> sources) - and W2K clients are very fast indeed with a
> Samba server :-) :-). It's very simple as all we're doing
> is telling W2k clients  "hey, we *already* support your large
> read/writes" - which we do !
> 
> Thanks a *lot* for making me spend the time to look at
> this......
> 
> 	Jeremy.
> 
> Index: include/smb.h
> ===================================================================
> RCS file: /data/cvs/samba/source/include/smb.h,v
> retrieving revision 1.325.2.24
> diff -u -r1.325.2.24 smb.h
> --- include/smb.h       18 May 2001 20:16:57 -0000      1.325.2.24
> +++ include/smb.h       23 May 2001 18:44:43 -0000
> @@ -1417,6 +1417,7 @@
>  #define CAP_NT_FIND          0x0200
>  #define CAP_DFS              0x1000
>  #define CAP_LARGE_READX      0x4000
> +#define CAP_LARGE_WRITEX        0x8000
>  #define CAP_EXTENDED_SECURITY 0x80000000
> 
>  /* protocol types. It assumes that higher protocols include 
> lower protocols
> Index: smbd/negprot.c
> ===================================================================
> RCS file: /data/cvs/samba/source/smbd/negprot.c,v
> retrieving revision 1.16.4.5
> diff -u -r1.16.4.5 negprot.c
> --- smbd/negprot.c      8 Mar 2001 14:49:28 -0000       1.16.4.5
> +++ smbd/negprot.c      23 May 2001 18:44:44 -0000
> @@ -160,6 +160,9 @@
>    /* dual names + lock_and_read + nt SMBs + remote API calls */
>    int capabilities = 
> CAP_NT_FIND|CAP_LOCK_AND_READ|CAP_LEVEL_II_OPLOCKS|
>                       (lp_nt_smb_support() ? CAP_NT_SMBS |
> CAP_RPC_REMOTE_APIS : 0) |
> +#if 1 /* JRATEST */
> +                                        CAP_LARGE_READX | 
> CAP_LARGE_WRITEX
> |
> +#endif
>                       (SMB_OFF_T_BITS == 64 ? CAP_LARGE_FILES : 0);
> 
> -- 
> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------
> 
>