RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1975775 - lmdb support is missing
Summary: lmdb support is missing
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: bind
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: Petr Menšík
QA Contact: Petr Sklenar
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-24 11:35 UTC by Petr Menšík
Modified: 2021-12-07 21:35 UTC (History)
2 users (show)

Fixed In Version: bind-9.16.20-2.el9
Doc Type: Enhancement
Doc Text:
Feature: Fast memory-mapped database support is enabled in BIND builds. It offers much faster additions and removals of zones added in runtime. Reason: Catalog Zone provides ability to setup secondary server hosting multiple zones, all of them configured by remote zone recipe received from another server. It then adds or removes served zones according to updates of the recipe zone. Result: A named server can add or remove high number of zones runtime without significant performance penalty.
Clone Of:
Environment:
Last Closed: 2021-12-07 21:33:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Internet Systems Consortium (ISC) isc-projects bind9 issues 2889 0 None None None 2021-08-30 12:33:59 UTC

Description Petr Menšík 2021-06-24 11:35:28 UTC
Description of problem:
LMDB can be used by BIND to store efficiently dynamically added zones via rndc addzone. Even when it works even without it, it uses inefficient text file parsing. It is unsuitable for working with higher number of dynamic zones.

This is important part of Catalog Zones [1] feature support, which I think would be interesting for our customers. Fedora builds have it enabled already, I think RHEL9 builds should them enabled too.

Version-Release number of selected component (if applicable):
bind-9.16.15-2.el9

How reproducible:
always

Steps to Reproduce:
1. add allow-new-zones yes; to options
2. use rndc addzone
3.

Additional info:

Slight disadvantage is lmdb would be required also by unrelated tools package bind-utils, but a size of lmdb-libs is only 100kB.

Adds new tool named-nzd2nzf, which converts binary lmdb database to text representation used without this feature.

1. https://kb.isc.org/docs/aa-01401

Comment 1 Petr Menšík 2021-06-24 12:39:14 UTC
Needs just change in spec to start building with LMDB.

diff --git a/bind.spec b/bind.spec
index e7ee351..5a7742b 100644
--- a/bind.spec
+++ b/bind.spec
@@ -21,7 +21,7 @@
 # kyua no longer in buildroot in RHEL9
 %bcond_with    UNITTEST
 %bcond_without DNSTAP
-%bcond_with    LMDB
+%bcond_without LMDB
 %bcond_without DOC
 # Because of issues with PDF rebuild, include only HTML pages
 %bcond_with    DOCPDF

Comment 11 Petr Menšík 2021-08-25 20:02:53 UTC
Fixed in build bind-9.16.20-2.el9

Additional test might check whether named-checkconf on contents:

options {
  lmdb-mapsize 24M;
};

Reports warning. It would return still $? == 0, but would print warning on version with disabled LMDB. It should not print anything if LMDB feature is enabled.

After rndc-addzone-delzone test finished, version with support LMDB should contain in /var/named files *.nzd, database files converted from original /var/named/*.nzf plain configuration files.
New tool named-nzd2nzf can be used to display its contents readable to humans.

bz1315821-rndc-addzone-delzone test should pass with or without LMDB feature, but with LMDB updates should be faster and able to handle singnificantly more zones added in dynamic way. Presence of *.nzd files should be indication of working LMDB support.

Comment 22 Petr Menšík 2021-08-30 12:13:31 UTC
We have found during testing LMDB database does not immediately flush changed lmdb database to disk. After adding or deleting zone via rndc addzone or rndc delzone, results are not immediately visible on disk file named-nzd2nzf /var/named/_default.nzd. However, after proper shutdown of named those records are stored on permanent disk store.

It changed the behaviour compared to plain text configuration of nzf, where it always rewrote <viewname>.nzf file right away. According to LMDB API [1], it should use mdb_env_sync() call to request flushing configuration to disk. rndc sync would be good candidate to do it. No such call is present in BIND 9.16.20 at the moment.

1. http://www.lmdb.tech/doc/group__mdb.html

Comment 24 Petr Menšík 2021-09-02 12:05:42 UTC
(In reply to Petr Menšík from comment #22)
> We have found during testing LMDB database does not immediately flush
> changed lmdb database to disk. After adding or deleting zone via rndc
> addzone or rndc delzone, results are not immediately visible on disk file
> named-nzd2nzf /var/named/_default.nzd. However, after proper shutdown of
> named those records are stored on permanent disk store.
> 
> It changed the behaviour compared to plain text configuration of nzf, where
> it always rewrote <viewname>.nzf file right away. According to LMDB API [1],
> it should use mdb_env_sync() call to request flushing configuration to disk.
> rndc sync would be good candidate to do it. No such call is present in BIND
> 9.16.20 at the moment.
> 
> 1. http://www.lmdb.tech/doc/group__mdb.html

Later testing contradicts those results and current tests do pass with checking of nzd database right after zone modification. I were unable to find why results are different now and what is the difference between previous testing results. Yet it is reliable and behaves the same even after retries.


Note You need to log in before you can comment on or make changes to this bug.