On Wed, Aug 10, 2005 at 11:05:06AM +0200, David Beck wrote: > Thank you for the suggestion. I'll keep the info for reference. > > Followup for the performance issue: > > The trace shows that the conversation changes right after the "trans2: > query file info internal" stage, so I looked into the samba code at this > file: > > http://websvn.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_3_0/source/smbd/trans2.c?rev=8959&view=markup > > case SMB_FILE_INTERNAL_INFORMATION: > /* This should be an index number - looks like > dev/ino to me :-) > > I think this causes us to fail the IFSKIT > BasicFileInformationTest. -tpot */ > > DEBUG(10,("call_trans2qfilepathinfo: > SMB_FILE_INTERNAL_INFORMATION\n")); > SIVAL(pdata,0,sbuf.st_dev); > SIVAL(pdata,4,sbuf.st_ino); > data_size = 8; > break; > > The comment speaks for itself. I suspect the 8 byte here contains some > magic that makes XP behaves as I found. > > I made an other experiment: I turned off the oplock support ("Oplocks = > No") and this made XP behave like if it was talking to a Windows server. > No extra tran2 calls and 1 byte writes. The performance got better > because the slowdowns disappeared, but it was still slower compared to > the windows machine.
Ok, I'm using the "disk test" part of www.passmark.com and can reproduce the "1 byte write every 64k followed by a qfilinfo" call against Samba, latest SVN code - but it also does the same against my Windows 2003 SP1 server.... BTW: - just using a cmd.exe prompt "COPY" command or using cut and paste from a Windows explorer Windows doesn't reproduce this problem, that writes completely normally. What Windows server are you using ? It looks like a reported allocation issue to me - but I'm still trying to understand what triggers this behaviour in the client ? Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
