[SSSD] [PATCH] Last USN patches

Stephen Gallagher sgallagh at redhat.com
Tue Apr 19 18:57:01 UTC 2011


On Tue, 2011-04-12 at 12:33 +0200, Jan Zelený wrote:
> Jan Zelený <jzeleny at redhat.com> wrote:
> > Simo Sorce <ssorce at redhat.com> wrote:
> > > 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.
> > 
> > Thanks for very detailed explanation Simo, I'm sending corrected patch in
> > attachment.
> 
> Can someone please take a look at the patch and ack that all issues discovered 
> by Simo have been corrected?
> 
> Also note that in the original email there is another patch, which hasn't been 
> reviewed yet.

Ack to both patches and pushed to master.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110419/59f4ff0c/attachment.sig>


More information about the sssd-devel mailing list