serverid(s)_exist, critical path work.

Ira Cooper ira at
Thu Feb 7 07:16:56 MST 2013

On Thu, Feb 7, 2013 at 8:03 AM, Volker Lendecke
<Volker.Lendecke at>wrote:

> On Thu, Feb 07, 2013 at 07:55:42AM -0500, Ira Cooper wrote:
> > On Thu, Feb 7, 2013 at 7:07 AM, Volker Lendecke
> > <Volker.Lendecke at>wrote:
> >
> > > On Thu, Feb 07, 2013 at 06:13:31AM -0500, Ira Cooper wrote:
> > > > >From Andrew Bartlett's review on IRC:
> > > >
> > > > Why remove TDB, isn't that a step backwards?
> > >
> > > To be honest, right now I'm in the mood to see this actually
> > > a step forward. fcntl sucks so badly that I would call it
> > > unusable. I am really ripping out my hair right now to
> > > replace it with something sane, although that turns out to
> > > be much more difficult than initially expected :-(
> >
> >
> >
> > The gap TDB fills must be filled by "X".  The general comment is sound,
> the
> > specific instance... well... I wrote the patch.
> >
> > Also note, I view what I'm doing as an "index" here, all the real data is
> > on the side, this is to speed up one very hot function.  The general
> > function of serverid.tdb should not be impacted.
> True. I just have my little tdb/fcntl-blues. I had thought
> that unix domain datagram sockets are really scalable, but
> that also seems not to be the case. My tests on FreeBSD and
> modern Linux also gave problems.

So it seems that the only really scalable IPC mechanism
> (scalable in terms of many, many thousand instances of
> *something*) seems to be epoll and its cousins on other
> OSes. I wonder if we can build something fast and robust
> upon those.

epoll and friends are very scalable for what they are, but you are still
taking a system call hit when you use them.  And at least on Solaris
that'll kill you.

Commenting on your patch: In theory, the load on
> serverid.tdb should be a lot less in master, as we do not
> look up every process anymore when reading a share mode
> record. We only do it when we have a conflict. I would be
> curious if this patch has a big effect when tested with
> master.

I'm not sure.  It needs measurement, I agree.  The merge to master is more
so I can merge back to 3.6, and gather comments for that merge.  (I'd hope
we can green light that once the review is done.)


More information about the samba-technical mailing list