Bug 8752 - dramatically decrease of copying parts of file on Sambe share in some conditions
Summary: dramatically decrease of copying parts of file on Sambe share in some conditions
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.5.12
Hardware: x64 Linux
: P5 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-08 19:35 UTC by Alexey Gankov
Modified: 2012-02-21 12:32 UTC (History)
0 users

See Also:


Attachments
strace -ttT -o /tmp/smbd.strace -p (47 bytes, text/plain)
2012-02-08 21:07 UTC, Alexey Gankov
no flags Details
strace and tcpdump from Samba (54 bytes, text/plain)
2012-02-10 08:23 UTC, Alexey Gankov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Gankov 2012-02-08 19:35:26 UTC
Users noted that the speed of file creation decreased after migrating to Samba (linux FC15 x64,3.5.12-72.fc15). We use specific software  that creates files on Samba Share.
I made test software (run on win7, comiled with borland C5.5):
#include "stdio.h"
#include "stdlib.h"
#include "time.h"
void main(int argc, char *argv[])
{
int fsize=40000000;
int i=0;
FILE *to;
char str[]="0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890";
time_t start, end;
double diff;
time(&start);
to=fopen(argv[1], "w+");
for(i=0; i < fsize/100; i++)
    {
        fprintf(to, "\n%7d-%s",i, str);
    fflush(to);
    }
fclose(to);
time(&end);
diff=difftime(end,start);
printf("\n \t time_diff =  %.2lf", diff);
}

The result (in my enviroment):
test.exe \\windows_share\test.txt  - 2 seconds
test.exe \\linux_samba_share\test.txt  - more than 35 seconds.

The same time, copying large file to\from samba share gives more than 75 mbytes/sec (over gigabyte ethernet)
Comment 1 Volker Lendecke 2012-02-08 20:45:00 UTC
Please upload a network trace and the output of

strace -ttT -o /tmp/smbd.strace -p <smbd-pid>

while you are doing the test.
Comment 2 Alexey Gankov 2012-02-08 21:07:23 UTC
Created attachment 7309 [details]
strace -ttT -o /tmp/smbd.strace -p
Comment 3 Volker Lendecke 2012-02-08 21:51:56 UTC
Without the network trace I can't say for sure, but to me it seems for some reason the file server does not grant an oplock. Can you check that?
Comment 4 Alexey Gankov 2012-02-10 08:23:20 UTC
Created attachment 7312 [details]
strace and tcpdump from Samba

Was made during running test program on Win7 x64 client:
test.exe y:\temp\test.txt
Comment 5 Volker Lendecke 2012-02-10 09:56:54 UTC
You might try upgrading to Samba 3.6.3 and the setting "max protocol = smb2"
Comment 6 Alexey Gankov 2012-02-16 16:10:38 UTC
(In reply to comment #5)
> You might try upgrading to Samba 3.6.3 and the setting "max protocol = smb2"

I got advice to try
strict allocate = yes option.
For the first view, it does the required speed improvement. But I still have idea to try Samba 3.6.3
Comment 7 Jeremy Allison 2012-02-17 00:53:35 UTC
Ok, so I can close this as "strict allocate = yes" fixes it ?

I am not surprised. When creating and allocating files using extents on an ext4 this would have that effect.

Jeremy.
Comment 8 Volker Lendecke 2012-02-21 12:32:45 UTC
Closing at reporter's request by private mail