<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Vicky,</p>
    <p>I never reflexively "howl in protest", but it's really hard to
      have an opinion on this proposal without some data.</p>
    <p>Clearly map format solved a big problem for some users.  Asking
      whether it's OK to drop it with no statement of what those users
      would give up today is not reasonable.</p>
    After all the "other improvements in performance" that you cited,
    what is the performance difference between map and the other
    formats?
    <p>For a case which took 'several hours' before map was introduced,
      what would the restart time be for named if raw format was used
      now?</p>
    <p>It's pretty clear to me that if map format saves a few seconds in
      the worst case, it's not worth keeping.  If it saves hours for
      large operators, then the alternative isn't adequate.  Maybe "map"
      isn't the answer - how might 'raw' compare to a tuned database
      back end?  (Which has other advantages for some.)  What if
      operators specified a priority order for loading zones?  Or zones
      were loaded on demand during startup, with low activity zones
      added as a background task?  Or???<br>
    </p>
    <p>A few data points would get you much more useful responses.  <br>
    </p>
    <p>A fair question for users would be what restart times are
      acceptable for their environment - obviously a function of the
      number and size/content of zones.  And is a restart "all or
      nothing", or would some priority/sequencing of zone availability
      meet requirements?<br>
    </p>
    <pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 
</pre>
    <div class="moz-cite-prefix">On 09-Sep-21 15:13, Victoria Risk
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:%3C97588CAA-E485-40D8-BE5A-2B8CE44FF71E@isc.org%3E">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class="">Greetings bind-users,</div>
      <div class=""><br class="">
      </div>
      <div class="">The `map` zone file format was introduced in BIND
        9.10. <a
href="https://bind9.readthedocs.io/en/v9_16_20/reference.html?highlight=map
          zone#additional-file-formats" class="" moz-do-not-send="true">https://bind9.readthedocs.io/en/v9_16_20/reference.html?highlight=map%20zone#additional-file-formats</a></div>
      <div class=""><br class="">
      </div>
      <div class="">At the time, this format significantly sped up a
        named restart, which could take several hours in some
        situations. This new file format is very complicated, and
        maintaining it has proven difficult. Meanwhile, the performance
        advantage versus the `raw` format, or the default text files,
        has decreased as we have made other improvements in
        performance. </div>
      <div class=""><br class="">
      </div>
      <div class="">We would like to deprecate the `map` zone file
        format in future branches of BIND. The proposal is to deprecate
        the feature in the 9.16 branch, (users will see a warning when
        this feature is used but it will still work through the end of
        the 9.16 branch), and to disable the feature in 9.20.0 (it will
        no longer work in this and subsequent versions). </div>
      <div class=""><br class="">
      </div>
      <div class="">Per our policy on deprecating named options, we are
        notifying the user mailing list.  You are welcome now to howl in
        protest or point out something we haven’t considered.  ;-)</div>
      <div class=""><br class="">
      </div>
      <div class="">Regards,</div>
      <div class=""><br class="">
      </div>
      <div class="">Vicky Risk</div>
      <div class="">Product Manager</div>
    </blockquote>
  </body>
</html>