ldap database went from 97meg to 86gig

[quanah]

What does 8.0.0 to 8.0.1 have to do with anything? It is going from ZCS7.x to ZCS8.x where total end DB size is unknown.
--Quanah

[CISX]

[quote user="quanah"]What does 8.0.0 to 8.0.1 have to do with anything? It is going from ZCS7.x to ZCS8.x where total end DB size is unknown.[/QUOTE]
Well I'd always argue, if you know what you are importing then you must be able to do some calculations. So let us assume that you don't know what you are importing then.
With a little bit of thought, the end size is known, even if it as after the event.

So you;

1) set the database allocated space to 86G

2) perform the upgrade/import

3) determine the actual space in use

4) adjust database allocation accordingly
However its a bit late in the day to be arguing about something that has already been done.

Let us just say that some more thought could have gone into the upgrade process.
At least you have done something about what people have commented on here and I commend you for that.

[quanah]

I think you don't understand what the maxsize setting is for. The point of the maxsize setting is to set it to such a large size as one expects the database to never reach.
There were some unfortunate bugs in the early ZCS8 releases that caused it to behave in ways that were not intended. Those are all now resolved. People who reduce the maxsize of the DB run the risk of later experiencing issues if the DB grows to fit within the size they adjusted it to.
With ZCS 8.0.4, we do have a script now that monitors the size of the DB relative to the maxsize, and will send emails to the admin account if it comes within certain thresholds. It can also reduce the maxsize of the DB so that it is no larger than the size of the disk.
Regardless, the current setting of 80GB is what is intended, and is not a mistake, nor in most cases should it be reduced.
--Quanah

[CISX]

[quote user="quanah"]I think you don't understand what the maxsize setting is for. The point of the maxsize setting is to set it to such a large size as one expects the database to never reach.[/QUOTE]

I don't think you understand good engineering principles, software practices, boundaries or limits.

Plucking a figure out of the air to cover everybodyÂ’s case is simply wrong.
I quote from OpenLDAP:

In addition to the usual parameters that a minimal configuration requires, the MDB backend requires a maximum size to be set. This should be the largest that the database is ever anticipated to grow (in bytes). The filesystem must also provide enough free space to accommodate this size.
[quote user="quanah"]

Regardless, the current setting of 80GB is what is intended, and is not a mistake, nor in most cases should it be reduced.[/QUOTE]
So given that our partition is only 100G, has only 50G of free disk space, how can you argue that your figure of 80G is correct. It is not correct and never will be for our system.

Additionally our system, being NE, we are locked into a maximum of 50 users. Yes we can add resources, and system users, but realistically we will never get beyond may be 100 accounts in total. Out current database size is 1.8M, so please tell me how many additional resources, system users or other accounts I would have to add before we reach 80G?
There are many ways of coming up with a sensible figure, but a "one number that fits all" approach is not one of them.

Would you build a bridge or an airplane with this approach – no, so please do not bang on about how the number you have chosen is correct.

[quanah]

This is the last I have to say on the topic:
I've been working with LDAP servers for over a decade. I've been working with OpenLDAP for longer than a decade. I've been a member of the OpenLDAP project team for over a decade. I work with Howard Chu, the primary OpenLDAP developer and author of MDB on a near daily basis. I'm very well versed in the fundamental workings of OpenLDAP and MDB. While that is indeed what the man page states, your missing an important point, which is that Zimbra's build of OpenLDAP uses the "writemap" flag, which creates a sparse file. Since it is a sparse file, it does not actually allocate 80GB of space. It simply has the potential to use up to 80GB of space. In any case, the number was not picked out of thin air, and it was picked for a reason. There has always been, since the switch to MDB, a way for end users to configure the MDB maxsize if they wanted it to be something other than 80GB. If you want to modify the size, feel free. That's why there is a key for it, and that's why it is documented.


--Quanah">https://wiki.zimbra.com/wiki/OpenLDAP_P ... Tuning_8.0
--Quanah