[SSSD] [PATCH] Last USN patches

Simo Sorce ssorce at redhat.com
Tue Mar 15 13:17:37 UTC 2011


On Tue, 15 Mar 2011 09:40:35 +0100
Jan Zelený <jzeleny at redhat.com> wrote:

> Simo Sorce <ssorce at redhat.com> wrote:
> > Sorry Jan but it doesn't seem to do what I asked for.
> 
> I'm not sure you are entirely right here. Let me explain:
> 
> > As far as I can see you are overriding the last_usn when you
> > connect, which is the exact opposite of what should be done.
> 
> No, I'm not overriding it. I suppose you are referring to the first
> patch (Add value of the last USN to server configuration). This is
> indeed adding the value of last USN to sdap_server_opts during
> connection, but this structure instance is only temporary and it is
> stored internally after the connection creating process is finished
> (see the second patch, the comparison of USN and server ID is in
> there).
> 
> > last_usn must never be set to whatever value is available from ldap.
> > 
> > You only need to check if the value from ldap is lower then the
> > currently internally value for last_usn if we are reconnecting to
> > the same server,and you need to reset last_usn to 0 if the highest
> > value reported from ldap is lower than the highest we internally
> > stored.
> > 
> > If we are connecting to a different server we always unconditionally
> > reset last_usn to 0, as USNs are not global so checking values
> > between different servers have no meaning.
> 
> I'm not sure we should be resetting the value to 0. Even after fresh
> replica installation the USN is not zero. In fact I didn't stumble
> upon a single case of USN being zero (considering that it was
> supported and used on the server). Can you please explain a little
> bit more why we should do this and not just leave the USN which is
> currently on the server?

The last usn on the server is simply used to keep track of what is the
highest usn used by the server.

The one we use internally instead is the higher usn of any entry we
actually *fetched* from the server.

So while we remain attached to the same server, and this server is
operating normally, the server's highest USN is always >= the one we
have on file.

If the server resets the USNs (this happen after a replica
re-initialization in 389 DS for example), then we want to set the
internal highest USN to 0 so that on the next enumeration search we will
search for any entry with USN > 0. Using any other value may result in
skipping entries that have changed between the time we fetched them
and the replica was re-initialized.

Same reasoning when we switch to a new server. Because USNs are not
global, each server has it's own USN number space, so when we switch we
have to reset to 0 as the highest USN we currently have on file has no
meaning and using it in a search may make us skip to search entries
that changed since our last fetch.
In extreme cases, if the new server have USNs that are much lower then
the ones in the previous server (because it was just re-initialized for
example), then we would fail to get any new change for potentially a
very long period of time, at least until something forces us to do a
full rescan, and yet because we do not reset the highest usn on a full
rescan we may still keep not getting changes after the full rescan.

So, setting the usn to 0 on a new connection (or a re-initialized
server) is fundamental, and setting it to the current reported highest
usn from the server is completely wrong and defeats the purpose.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


More information about the sssd-devel mailing list