Samba Performance on Solaris 7/8 (oplocks)

David Collier-Brown -- Customer Engineering David.Collier-Brown at Sun.COM
Tue Mar 11 20:59:25 GMT 2003


Could someone add a one-liner to the FAQs about
the .mdb/.dbf/.shp spcial case?

--dave

John wrote:
| I did.  The ESRI MapObjects part of our application,
| however, doesn't like being denied an exclusive lock on
| those .shp files -- despite the fact that it only needs
| to open them for read access.

| Fake oplocks more/less a workaround for MapObjects.
| It's just unfortunate that you have to apply fake
| oplocks to the entire service and not just the
| .shp extension.


-----Original Message-----
From: David Collier-Brown -- Customer Engineering
[mailto:David.Collier-Brown at Sun.COM]
Sent: Tuesday, March 11, 2003 2:37 PM
To: Nastasi, John
Cc: 'davecb at canada.sun.com'
Subject: Re: FW: Samba Performance on Solaris 7/8

    Possibly dumb question: didn't you say you tried
veto oplock files = /.mdb/.dbf/.shp/

--dave (whose short-term memory is starting to go (;-)) c-b


Nastasi, John wrote:
 > David,
 >
 > Just as a follow-up, I wanted to pass along that by adding...
 >
 > Oplocks = False
 > Fake Oplocks = True
 >
 > ...to the service, it appears to have fixed the problem.  Since none of
the
 > .MDB, .DBF, or .SHP files should ever be written to (by our app -- in
 > theory) I'm anxious to see if any data corruption issues result.
 >
 > If Samba had a way to fake oplocks for just a certain file type (mainly
 > .SHP) it seems like that would be the ideal way to go.  That would 
allow
 > MapObjects to "believe" it had an exclusive on .SHP files -- which it
really
 > doesn't require -- and other file types including .MDB and .DBF to be
 > excluded from oplocking altogether.
 >
 > John Nastasi
 >
 >
 > -----Original Message-----
 > From: David Collier-Brown -- Customer Engineering
 > [mailto:David.Collier-Brown at Sun.COM]
 > Sent: Tuesday, March 11, 2003 9:00 AM
 > To: Nastasi, John
 > Cc: 'davecb at canada.sun.com'
 > Subject: Re: Samba Performance on Solaris 7/8
 >
 > Nastasi, John wrote:
 >
 >>Do you know if there are any issues with Samba running on Solaris that
 >>would cause the application to run "very, very" slow with oplocks 
turned
 >>off?
 >
 >
 > 	No, and that's the kind of problem we should
 > 	raise with the Samba team: I'm cc'ing this
 > 	to them.
 >
 >
 >
 >>Specifically, with oplocks turned on I get acceptable performance
 >>trying to open an MS-Access (Jet) database.  The operation 
completes in
 >>no more than a minute or so.  Turning "off" oplocks (as suggested
 >>repeatedly by many folks for multiple users accessing an MDB on a 
Samba
 >>share) completely hoses the same operation - 9 minutes to complete.
 >
 >
 > 	We need to see what Samba's doing differently
 > 	between the two cases. There are three places to
 > 	look:
 > 	1) Samba logs, at log level = 3 or more
 > 	2) truss reports
 > 	3) packet dumps.
 >
 > 	I recommend them in roughly that order: I'm
 > 	good at reading truss, and the team is real good
 > 	at logs.
 >
 >
 >>I've tried the configuration on a Solaris 7 (Ent 4500) running Samba
 >>2.0.10 and also on a Solaris 8 (V100) running Samba 2.2.7a - same
 >>result.  I'm about to try the latest kernel patch to see if it 
could be
 >>an fcntl related issue, but was curious if you knew of anything else
 >>that could be causing the problem.
 >>
 >>Based upon what I've read - oplocks being turned off should "help"
 >>multi-user, MDB access performance.  What I'm seeing, however, is just
 >>the opposite.
 >
 >
 > 	Yes, specifically by avoiding transferring the
 > 	whole file to the client and then transferring it back.
 > 	Turning of oplocks **in principle should** cause
 > 	the db to read only the records it wants to change,
 > 	then writing them back.
 >
 > 	The times imply it's still transferring the whole
 > 	file, which is utterly evil (;-))  Of course, using
 > 	smb file locking as the mechanism to do database locking
 > 	is brain-dead in the first place. Being able to do
 > 	so is just a way of letting you try out a DBMS, get
 > 	used to it and eventually buy the back-end DBMS and
 > 	a server to put it on.
 > 	
 >
 > --dave
 >


-- 
David Collier-Brown,           | Always do right. This will gratify
Sun Microsystems DCMO          | some people and astonish the rest.
Toronto, Ontario               |
(905) 415-2849 or x52849       | davecb at canada.sun.com





More information about the samba-technical mailing list