On Tue, 2011-04-12 at 12:33 +0200, Jan Zelený wrote: > Jan Zelený <jzel...@redhat.com> wrote: > > Simo Sorce <sso...@redhat.com> wrote: > > > On Tue, 15 Mar 2011 09:40:35 +0100 > > > > > > Jan Zelený <jzel...@redhat.com> wrote: > > > > Simo Sorce <sso...@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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
