BIND 10 #2441: update in-memory data source so it can load RRs in any order

BIND 10 Development do-not-reply at isc.org
Mon Mar 4 17:31:27 UTC 2013


#2441: update in-memory data source so it can load RRs in any order
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  data source   |                    Milestone:
            Keywords:                |  Sprint-20130305
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 vorner]:

 > This comment contains „existing“ one too many times:
 > {{{#!c++
 > // Create a new RdataSet, merging any existing existing NSEC3 data
 > }}}
 >
 > Also, the original code collated the RRsets before it put them into the
 zone updater. Currently, it doesn't do so. I'm not sure how fast it'll be
 to repeatedly merge the RRs together, because each time a new (larger) one
 is allocated. Couldn't it lead to severe memory fragmentatiton? Would it
 be better to keep the collating and use the merging only at the times the
 RRs are not consecutive? On the other hand, this code is simpler, which is
 an advantage, so I don't know.

 If this means trac2441 calls the extended `RdataSet::craete()` for
 each RR of the same RRset, that implementation would be very
 inefficient.  While efficiency is always subject to actual
 measurement in the end, I'd generally avoid that overhead.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2441#comment:9>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list