Hi,
the attached patch was confirmed to work, so the code review should be
easy. But because it adds an index to objectSID, which all AD objects
have, there are two catches:
1) How log the upgrade takes
2) How much the database grows
To test, I created an AD instance with 10.000 users and 10.000 groups
(adcli is great for this type of testing btw). Fetched all groups and
users with the old db, then ran the upgrade.
On a VM running on my local laptop (granted, it has an SSD drive), the
upgrade takes 10 seconds. The default systemd startup timeout
(DefaultTimeoutStartSec) seems to be 90 seconds, which sounds OK to me.
The size, though, has nearly doubled. This is backup before upgrade:
[root@adclient ~]# du -sh /root/cache_win.trust.test.ldb
47M /root/cache_win.trust.test.ldb
And this is the cache after I upgraded:
[root@adclient ~]# du -sh /var/lib/sss/db/cache_win.trust.test.ldb
97M /var/lib/sss/db/cache_win.trust.test.ldb
Unfortunately, I don't see us having another option than doing the
upgrade. For attributes that are indexed, an index miss means that ldb
is not going to search sequentially, but just return not found -- so
adding indexes for newly added entries is not possible.
I would like to document that for huge databases (tens of thousands of
cached entries), the timeout might need to be raised during the upgrade
and than for deployments whose cache resides in tmpfs, the cache size
might grow.
Is everyone OK with this?