BIND - sorting of reverse domain.
David Botham
dns at botham.net
Wed Jul 10 21:22:14 UTC 2002
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of D. Stussy
> Sent: Wednesday, July 10, 2002 4:04 PM
> To: comp-protocols-dns-bind at isc.org
> Subject: Re: BIND - sorting of reverse domain.
>
>
> On 9 Jul 2002, Danny Mayer wrote:
> >At 03:57 AM 7/9/02, D. Stussy wrote:
> >> Furthermore, the RFC requires an order
> >>for the MEMORY IMAGE, but again, that isn't relevent to the FILE
image I
> >>queried
> >>about.
> >
> >RFC's don't care about memory image. Making such a statement shows
that
> >you didn't bother to actually read them. Memory Image is an
> implementation
> >detail rightly left to the implementors.
>
> So, algorithic implications made by certain requirements of the RFC's
have
> no
> bearing whatsoever? I'll agree that it doesn't come straight out and
say
> that
> one must use structure "x", ....
>
> >>Since others said that a zone ISN'T stored in alphabetical/machine
> order,
> >>but is
> >>written out as such, I properly concluded that before writing, an
> additional
> >>sort of the zone names was occuring so as to make the file listing
of
> the zone
> >>appear in a human readable pattern. It wasn't until later that they
> finally
> >>admitted that it was a side-effect of their tree-traversal (which
> >>coincidentally, did traverse the tree in machine order to write the
> file) -
> >>which means that it IS in fact sorted in machine order to begin
> >>with. Beyond my
> >>query, my assertions were as a result of their false statements.
> >
> >Noone made any false statements to you. You just didn't understand
the
> >answers when given.
>
>
> >>My follow-up question, once I overcame their falsehoods, then was:
Why
> was it
> >>chosen to save the file in machine order when that requires a tree-
> rebalance
> >>performance penalty when reading it back in (upon restart)? If it
is
> saved in
> >>this other tree traversal order, the rebalance penalty is completely
> >>avoided (as
> >>long as the zone file hadn't been tampered with in the meantime). I
> still
> >>await
> >>an answer to that one.
> >
> >Noone really cares. The file is written the way it is due to the way
the
> >tree is
> >traversed. The file when read back in is read record by record and
each
> one is
> >added to the tree in the appropriate place. What's the real issue?
>
> The fact that if we write it using a different transversal (by a mere
> rearrangment of the existing statements), we can avoid certain
performance
> penalties (i.e. having to resort/rebalance the zone) in certain
> circumstances.
> Since everyone has said that the current traversal order is arbitrary,
> then one
> order is as good as another. I have given you an alternative order
that
> has an
> efficiency side-effect; a reason to use it over the others. Is there
a
> good
> reason NOT to use it?
As previously stated, your comments, and this line of discussion, are
probably more appropriate for the bind-workers list. Try
http://www.isc.org
Dave...
More information about the bind-users
mailing list