[Samba] Re: How Samba let us down

Matthew Hannigan mlh at zip.com.au
Fri Oct 25 01:06:06 GMT 2002

On Thu, Oct 24, 2002 at 10:44:28AM -0500, Steve Langasek wrote:
> On Thu, Oct 24, 2002 at 01:08:10PM +1000, Matthew Hannigan wrote:
> > And Solaris?  At least they're autoconfigured to assume kernel oplocks
> > according to testparm, and the docs say this is done only if the support
> > is there.
> smb.conf(5):
>        kernel oplocks (G)
>               [...]
>               This parameter defaults to on, but is translated to
>               a no-op on systems that no not have  the  necessary
>               kernel  support.   You  should  never need to touch
>               this parameter.

Ok, thanks I should have read more closely.  May I respectfully
suggest that this is forced off for those Unices without kernel
support rather than silently ineffective?

> [ .. ]
> Real locks are always implemented using the available Unix facilities
> for such, so any Unix app that implements locking properly will see the
> Samba locks.

Excellent, so two otherwise separate Sambas, say,
with oplocking off and strict locking
on would play nicely together if sharing the same

> Note the hedging here: there are many different historical
> locking mechanisms available on Unix, some of which are invisible to one
> another;

Understood.  I've done some reading recently and my brain hurts.

There is
(and of course these are not exclusive with respect to each other)

	mandatory lcking
	advisory locking
	opportunistic "locking"
	kernel locking
	user level locking
	locks implemented with symlinks
	locks implemented with mkdir
	locks implemented with open( ... O_CREAT|O_EXCL)
	flock locking
	lockf locking
	fcntl locking

As far as I can see, NONE of these are will necessarily
work with each other.

And even if you use a single type (fcntl), recent Samba
dsicussion shows that there can be scalability issues
with Solaris.


More information about the samba mailing list