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