https://bugs.openldap.org/show_bug.cgi?id=9735
--- Comment #7 from [email protected] --- @jtgrassie Well, for the sake of clarity, let's distinguish: - growth(1): increasing the LMDB data file size within the limit of pre-configured (and static) Mapsize - growth(2): increasing the Mapsize Do you suggest that when the free space in given env is not found (e.g. due to free space fragmentation), it's desirable to grow(2) ? I guess the code of LMDB internally never does this, but it's of course possible to implement in the application some logic like: - try to commit a RW txn - if MDB_MAP_FULL is encountered, grow(2) and re-try ...but there would always need to be _some_ limit (e.g. available disk space). Could you discuss why wouldn't one configure the Mapsize to _that_ very maximal limit already at the beginning and rely only on growth(1) which is much less complicated? >From my point of view, the situation looks quite simple: - set the Mapsize to the highest possible limit - the DB will probably never reach it, enjoying the performance-size-trade-off when searching for available free chunk - when the fragmentation goes so bad that it actually reaches the limit, it's always better to sacrifice the performance than failing to write data (with no possibility of any growth) But if you could sketch different reasonable operation modes, i'd be glad :) -- You are receiving this mail because: You are on the CC list for the issue.
