[Samba] Re: How Samba let us down
Matthew Hannigan
mlh at zip.com.au
Fri Oct 25 01:05:01 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
files.
> 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.
Regards,
Matt
More information about the samba-technical
mailing list