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
Created attachment 5043 [details] output from strace
Created attachment 5044 [details] smb.conf from running cluster
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
Created attachment 5045 [details] output from strace -ttT as requested, previous I had a typo (-ttF)
Try "kernel oplocks = false" please. Volker
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
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
There's a known bug that smbd does not pick up registry changes dynamically. Unfortunately you have to restart it. Sorry, Volker
Did a SIGHUP against the main smbd on both nodes. Also set log level to 10, see attachment. Matthias
Created attachment 5046 [details] level 10 log
Please restart smbd. Thanks, Volker
"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 :)