Bug 6956 - slow write from Corel X3
Summary: slow write from Corel X3
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.3
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.3.7
Hardware: x64 Windows 7
: P3 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-02 11:21 UTC by Matthias Grimm
Modified: 2009-12-03 03:05 UTC (History)
0 users

See Also:


Attachments
output from strace (552.78 KB, application/octet-stream)
2009-12-02 11:23 UTC, Matthias Grimm
no flags Details
smb.conf from running cluster (2.86 KB, application/octet-stream)
2009-12-02 11:26 UTC, Matthias Grimm
no flags Details
output from strace -ttT (266.24 KB, application/octet-stream)
2009-12-02 11:39 UTC, Matthias Grimm
no flags Details
level 10 log (92.96 KB, application/x-gzip)
2009-12-02 12:10 UTC, Matthias Grimm
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Grimm 2009-12-02 11:21:39 UTC
User tried to write a *.cdr file to his homedir, which is on our cluster, and complaines poor performance from windows XP. Writing the file to our old Novell Servers succeeded without a hitch. 
I've installed Corel X3 afterwards on my PC and ran into the same problem. 
When Corel writes the file it creates a fiel named @@@CDRW.TMP with 0 bytes and correct permission. This file sit there for ~30 seconds and gets deleted when Corel finishied saving.

Saving/copying files from Word, Illustrator works fine, even with unusual character sets, like cyrillic.


Environment:

Two clusternodes on CentOS 5.3 x64, shared storage connected over FC, FS is GPFS 3.2.1-12
samba is still on 3.3.7, ctdb on 1.0.84
All in a Windows 2003 Domain.

vl told me on IRC to strace the smbd PID, which I'll attach. 

Matthias
Comment 1 Matthias Grimm 2009-12-02 11:23:16 UTC
Created attachment 5043 [details]
output from strace
Comment 2 Matthias Grimm 2009-12-02 11:26:31 UTC
Created attachment 5044 [details]
smb.conf from running cluster
Comment 3 Volker Lendecke 2009-12-02 11:27:53 UTC
Please do the strace with -ttT, we need to know if it's really the unlink syscall in line 308 that took so long.

Also, debug level 10 might help figuring out the status of oplocks and share modes.

Volker
Comment 4 Matthias Grimm 2009-12-02 11:39:07 UTC
Created attachment 5045 [details]
output from strace -ttT

as requested, previous I had a typo (-ttF)
Comment 5 Volker Lendecke 2009-12-02 11:41:19 UTC
Try "kernel oplocks = false" please.

Volker
Comment 6 Matthias Grimm 2009-12-02 11:41:44 UTC
one thin I've noted while making the trace: a 'smbstatus | grep mgr' takes very long while Corel tries to write and only keeps on going after that write operation

Matthias
Comment 7 Matthias Grimm 2009-12-02 11:47:32 UTC
set that option (net conf setparm... ), but it doesn't make a change. I didn't restarted samba since there are still ~50 people working.  

Matthias
Comment 8 Volker Lendecke 2009-12-02 11:55:32 UTC
There's a known bug that smbd does not pick up registry changes dynamically. Unfortunately you have to restart it.

Sorry,

Volker
Comment 9 Matthias Grimm 2009-12-02 12:08:34 UTC
Did a SIGHUP against the main smbd on both nodes. Also set log level to 10, see attachment.

Matthias
Comment 10 Matthias Grimm 2009-12-02 12:10:17 UTC
Created attachment 5046 [details]
level 10 log
Comment 11 Volker Lendecke 2009-12-02 12:12:21 UTC
Please restart smbd.

Thanks,

Volker
Comment 12 Matthias Grimm 2009-12-03 03:05:03 UTC
"kernel oplocks = false" fixed it. After logoff yesterday and login today Corel writes the file within the blink of an eye.

For me it seems to be fixed and could be closed.

Thank you, Volker :)