[PATCH] current notify work

Amitay Isaacs amitay at gmail.com
Wed Nov 26 06:26:22 MST 2014

Hi Volker,

On Tue, Nov 25, 2014 at 2:11 AM, Volker Lendecke <Volker.Lendecke at sernet.de>

> Hi!
> Attached find my current patch series for the new messaging
> based notify infrastructure. A lot of those patches are
> preparatory and already carry a Signed-off-by me. I'd
> appreciate if someone took the time to take a look and
> potentially push some of them.
> The big one is patch 35. It adds the notify daemon as a
> tevent_req based engine that can be forked or run as part of
> any tevent loop with a messaging context.
> If you take a look at the "+" lines of patch 39 you see why
> I'm doing this: All the hard work in notify_trigger is
> replaced with one single messaging_send_iov call which boils
> down to one single sendmsg call to the notify daemon. In
> particular in a cluster environment the dbwrap_parse calls
> really, really hurt performance.
> Also we use just one single inotify listener inside the
> notify daemon, the individual smbds don't do that anymore.
> The architecture is such that we get clusterwide notifies
> working correctly cross-protocol. I'm not aware of a cluster
> file system giving us clusterwide inotify, but with this
> code you can smb-mount on node a, nfs mount on node b, and a
> new file coming in via nfs shows up on the smb-mount via
> notify.
> It would be trivial to add a simple protocol listener
> available for NFS servers to enable recursive notifies
> cross-protocol, something which inotify won't give us.
> Ganesha could send us a unix dgm message whenever it changes
> something and we sort out the recursive side of things.
> There is one little downside of the code: "kernel change
> notify" and "change notify" become global parameters. Also,
> "notify:inotify" becomes a global choice, as does
> "notify:fam". notifyd does not see shares at all, it only
> deals with path names.
> There are very few loose ends, smbstatus -N does not work
> yet, and I did not yet implement the timestamp based
> fallback that I've talked about at SambaXP and SDC. But the
> basic engine works and survives autobuild.
> The whole thing is
>  75 files changed, 4051 insertions(+), 2259 deletions(-)
> so there's quite a bit to read.
> Comments?

Do you have these patches in a tree somewhere?  They don't apply to current


More information about the samba-technical mailing list