-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/27/2016 09:21 AM, John Hodrien wrote:
On Wed, 27 Jan 2016, Stephen Gallagher wrote:
Now, I can certainly see an argument for having such a nosync (or deferred sync) option for machines that are expected to always be connected to the identity network (and as such are using SSSD mostly for performance and surviving the occasional outage hiccup). But I'd say that such an option, if added, should be VERY carefully documented to explain all of the things that could go wrong.
I don't disagree with what you've said, and it's exactly this situation I'd be interested in. If they're a road warrior, I'd be much less likely to enable nosync.
As an aside, there are plenty of other things that can go wrong when the cache is deleted, including manual overrides from the sss_override command as well as ID ranges if any of them had hash collisions or were using the autorid compat mode.
Sure, but none of this ends up being worse than using tmpfs, which we currently resort to in order to get acceptable performance. nosync with canary sounds like it can only be better in my situation.
Actually, there is one slight difference: tmpfs won't persist across a reboot, but with the nosync-and-canary, it's possible that the cache could be destroyed during an SSSD package upgrade (for example).
Let's say that we introduced a bug and the canary doesn't get written in all cases (maybe we have a crash-on-shutdown bug somewhere). If you do a `yum|dnf update sssd`, this will restart SSSD as part of the process, to ensure that you are running the latest bits. If we crash during the shutdown, this restart might delete the cache unexpectedly.