samba - Mar 2006 - 1 byte writes

After migrating a particular W2K file service to Samba 3.0.21c on SuSE 
9.3 Pro (a DMS with winbindd against a W2K3 ADS), the W2K clients are 
suffering performance issues (in a switched LAN).

Looking at the traffic with Ethereal (latest SVN), it looks like the 
client writes the data in *1 byte* pieces likes this (c=client, s=server):

c->s NT Create AndX Request
c<-s NT Create AndX Response
c->s Trans2 Request, SET_FILE_INFO
c<-s Trans2 Response
c->s Trans2 Request, QUERY_FILE_INFO, Query File Basic Info (1004)
c<-s Trans2 Response
c->s Write AndX Request, 1 byte at offset 119  <-- sigh
c<-s Write AndX Response, 1 byte
c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
c<-s Trans2 Response
c->s Write AndX Request, 1 byte at offset 155  <-- sigh again
c<-s Write AndX Response, 1 byte
c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
c<-s Trans2 Response
c->s Write AndX Request, 1 byte at offset 191  <-- see above
c<-s Write AndX Response, 1 byte
...
c->s Write AndX Request, 1 byte at offset 6629781  <-- 100 secs later!!
c<-s Write AndX Response, 1 byte
c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
c<-s Trans2 Response
c->s Write AndX Request, 4096 bytes at offset 0  <-- the file header?
c<-s Write AndX Response, 4096 bytes
c->s Write AndX Request, 2454 bytes at offset 6627328  <-- strange
c<-s Write AndX Response, 2454 bytes
c->s Flush Request
c<-s Flush Response
c->s Close Request
c<-s Close Response

resulting in incredibly poor write performance. Does this ring a bell 
with anyone?

Searching the list archives, this issue seems to be only known with 
particular poorly-written applications:

http://groups.google.com/group/mailing.unix.samba/browse_thread/thread/89c619c8ea1e48/256e1ebf227819cc

but we're running none of those mentioned there (but may have found yet 
another ;-)).

Then, still, there haven't been any noticeable performance issues with 
the same application against the original W2K file server, so /me ends 
up as the one being pointed at. :-(

smb.conf global settings are the same as in an earlier thread 
(http://lists.samba.org/archive/samba/2006-February/118057.html) plus 
the following share-level settings:

[grp$]
         path = /cifs/grp
         valid users = +XXX\mygroup
         read only = No
         create mask = 0770
         directory mask = 0770
         nt acl support = Yes
         acl group control = Yes
         map acl inherit = Yes


Any ideas?


-TL

Hi Thomas,
i dont see any bugs in your conf,
but in general there is no performance issue known to me
with current samba, what are the samba log say , or/and tcpdump
have you firewall on the server etc how is your setup in wins browsing
have you tested another nic
Bets Regards

Thomas Limoncelli schrieb:
> After migrating a particular W2K file service to Samba 3.0.21c on SuSE 
> 9.3 Pro (a DMS with winbindd against a W2K3 ADS), the W2K clients are 
> suffering performance issues (in a switched LAN).
> 
> Looking at the traffic with Ethereal (latest SVN), it looks like the 
> client writes the data in *1 byte* pieces likes this (c=client, s=server):
> 
> c->s NT Create AndX Request
> c<-s NT Create AndX Response
> c->s Trans2 Request, SET_FILE_INFO
> c<-s Trans2 Response
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Basic Info (1004)
> c<-s Trans2 Response
> c->s Write AndX Request, 1 byte at offset 119  <-- sigh
> c<-s Write AndX Response, 1 byte
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
> c<-s Trans2 Response
> c->s Write AndX Request, 1 byte at offset 155  <-- sigh again
> c<-s Write AndX Response, 1 byte
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
> c<-s Trans2 Response
> c->s Write AndX Request, 1 byte at offset 191  <-- see above
> c<-s Write AndX Response, 1 byte
> ...
> c->s Write AndX Request, 1 byte at offset 6629781  <-- 100 secs
later!!
> c<-s Write AndX Response, 1 byte
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
> c<-s Trans2 Response
> c->s Write AndX Request, 4096 bytes at offset 0  <-- the file header?
> c<-s Write AndX Response, 4096 bytes
> c->s Write AndX Request, 2454 bytes at offset 6627328  <-- strange
> c<-s Write AndX Response, 2454 bytes
> c->s Flush Request
> c<-s Flush Response
> c->s Close Request
> c<-s Close Response
> 
> resulting in incredibly poor write performance. Does this ring a bell 
> with anyone?
> 
> Searching the list archives, this issue seems to be only known with 
> particular poorly-written applications:
> 
>
http://groups.google.com/group/mailing.unix.samba/browse_thread/thread/89c619c8ea1e48/256e1ebf227819cc
> 
> 
> but we're running none of those mentioned there (but may have found yet
> another ;-)).
> 
> Then, still, there haven't been any noticeable performance issues with 
> the same application against the original W2K file server, so /me ends 
> up as the one being pointed at. :-(
> 
> smb.conf global settings are the same as in an earlier thread 
> (http://lists.samba.org/archive/samba/2006-February/118057.html) plus 
> the following share-level settings:
> 
> [grp$]
>         path = /cifs/grp
>         valid users = +XXX\mygroup
>         read only = No
>         create mask = 0770
>         directory mask = 0770
>         nt acl support = Yes
>         acl group control = Yes
>         map acl inherit = Yes
> 
> 
> Any ideas?
> 
> 
> -TL

On Wed, Mar 08, 2006 at 07:06:58PM +0100, Thomas Limoncelli
wrote:
> After migrating a particular W2K file service to Samba 3.0.21c on SuSE 
> 9.3 Pro (a DMS with winbindd against a W2K3 ADS), the W2K clients are 
> suffering performance issues (in a switched LAN).
> 
> Looking at the traffic with Ethereal (latest SVN), it looks like the 
> client writes the data in *1 byte* pieces likes this (c=client, s=server):
> 
> c->s NT Create AndX Request
> c<-s NT Create AndX Response
> c->s Trans2 Request, SET_FILE_INFO
> c<-s Trans2 Response
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Basic Info (1004)
> c<-s Trans2 Response
> c->s Write AndX Request, 1 byte at offset 119  <-- sigh
> c<-s Write AndX Response, 1 byte
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
> c<-s Trans2 Response
> c->s Write AndX Request, 1 byte at offset 155  <-- sigh again
> c<-s Write AndX Response, 1 byte
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
> c<-s Trans2 Response
> c->s Write AndX Request, 1 byte at offset 191  <-- see above
> c<-s Write AndX Response, 1 byte
> ...
> c->s Write AndX Request, 1 byte at offset 6629781  <-- 100 secs
later!!
> c<-s Write AndX Response, 1 byte
> c->s Trans2 Request, QUERY_FILE_INFO, Query File Standard Info (258)
> c<-s Trans2 Response
> c->s Write AndX Request, 4096 bytes at offset 0  <-- the file header?
> c<-s Write AndX Response, 4096 bytes
> c->s Write AndX Request, 2454 bytes at offset 6627328  <-- strange
> c<-s Write AndX Response, 2454 bytes
> c->s Flush Request
> c<-s Flush Response
> c->s Close Request
> c<-s Close Response
> 
> resulting in incredibly poor write performance. Does this ring a bell 
> with anyone?
What the client is trying to do is extend the file here.

It's writing one byte at increasingly large offsets to
force the filesystem to extend the allocated storage (as
sparse files are rare on NTFS and of course what other
filesystems are there :-). Have you tried playing with
the allocation size ? We normally report it as 1 meg to
stop the clients doing such stupidity.

Jeremy.