-----BEGIN PGP SIGNED MESSAGE-----
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
be interested in. If they're a road warrior, I'd be much less likely to
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----