Samba 3.0.32 - oplock code

Jeremy Allison jra at
Thu Dec 11 19:34:44 GMT 2008

On Thu, Dec 11, 2008 at 11:26:32AM -0800, Jeremy Allison wrote:
> On Thu, Dec 11, 2008 at 07:18:14PM +0200, Itay Dar wrote:
> > Hi, 
> > 
> > We are working on a cluster, so if the process will die in the middle of
> > the change phase you are proposing, a state corruption will occur.
> > So this makes life hard on us, as we need to start working with
> > transactions (I think the ctdb project will have the same issues, but I
> > am not sure, I plan to look on it also)
> Well if smbd dies inside any number of places
> then state corruption occurs. I'm not sure that
> is a deal-breaker. How likely is this problem
> to occur ?

In fact thinking about this further, having
the writing process hold the lock, send the
messages, then iterate over the share mode
data changing the type from level2 -> none
is the simplest way to fix this, and means
the least code changes I can see.

How is this more dangerous than any
other places where we hold the lock
and iterate over the data and change it
(when we're validating existing share
modes on open, for example ) ?

Under a cluster system you'll hold
the lock and change the data under
a transaction anyway, so no change


More information about the samba-technical mailing list