windows 2000: slow file copy from windows 2000 to SAMBA
Ulf Bertilsson
ulf.bertilsson at adcomdata.no
Wed May 23 22:05:52 GMT 2001
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.
> --------------------------------------------------------
>
>
More information about the samba-technical
mailing list