Production environment is Samba-2.0.7 on AIX 5.1 in a NT4 domain with mutually
trusts to an ADS domain where users are defined.
Test environment is Samba-3.0.4 in a NT4 based domain where problem can be
reproduced. We experience serious performence problems on some Word documents
having tables. Opening takes long time compared with other files and editing
within the document is a pain as just moving the mouse curser to another
table-cell takes up to several minutes. Net-traces indicates that oplocks are
broken and that local caching of file is not effective. With "Veto oplock file"
set to *.xls we cannot reproduce the same strange behavour with excel files so
problem seems to be isolated to Word docs with special formatting.
Created attachment 555 [details]
Specific MS word document formatted with tables.
This MS Word doc formatted with tables is a sample of the documents giving a
very slow response while editing.
Created attachment 556 [details]
Network trace between Win 2k client and Samba server
Created attachment 557 [details]
Samba debug 10 log
Action takes place within the first 10 Mb of the trace.
Trace taken at the same time as the network trace
Created attachment 558 [details]
Only smb.conf from a 2.2.6 version available at this time but this has been
used as a base for 3.0.4 where winbind parameters were added and "domain" level
security selected instead as "server".
it seems like that setting
oplocks = NO
in the smb.conf file may work as a workaround, but I so nat know the real
impact of this setting, having looked true the docu, i could be some problems
in the locking mechanisme SAMBA/WINDOWS/DOS - OR ??
Med venlig hilsen/Kind regards
Senior IT Specialist - FTSS
Deep Computing - Nordic Technical Presale - pSeries
Systems and Technology Group
IBM Danmark A/S
+45 2880 4074 [GSM]
This won't give you locking problems. This causes only that client won't cache
the document on his side. This can give a little performance loss.
But in your case it will make your life easier and performance increase :)
please retest against 3.0.11 and reopen if necessary. Thanks.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.