Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!hplabs!oliveb!jerry
From: jerry@oliveb.olivetti.com (Jerry Aguirre)
Newsgroups: news.admin
Subject: Re: Map expiration dates
Message-ID: <12829@oliveb.olivetti.com>
Date: 14 Jan 88 01:23:53 GMT
References: <2323@cxsea.UUCP> <7815@rutgers.rutgers.edu>
Reply-To: jerry@oliveb.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 45

In article <7815@rutgers.rutgers.edu> pleasant@rutgers.rutgers.edu (Mel Pleasant) writes:
>Given this response, there will no doubt be other comments vis a vis the map
>posting procedures.  I'm all ears.  For those of you interested in lowering
>the volume, here is a challenge for you.  How can it be done such that we
>never have to make a full one-shot posting of all of the files ever again?

There is an obvious solution that has been previously suggested.  Break
the d.* and u.* files into the individual sites.  This is the increment
that gets changed when a site sends in an update or a new entry.  It
also represents the minimum useful stand alone value.

Getting patches when you don't have the original does cause problems.
But if I get the entire new entry for a site then it is useful without
the other entries in that particular [du].* file.  It also becomes
simple to find and distribute entries that haven't been updated in N
months.

The only disadvantage that I can see is that is will use up more inodes
and disk space.  Right now we have ~140 [du].* files containing ~4000
site entries using about 1.7Meg.  Splitting this out would create 4000
files using about 3 Meg.  The directories could be kept reasonable by
using something like u/usa/ca/site to contain each entry.  It has also
been pointed out that a simple program could pack this into less space
and still provide individual site updates.  How about using "ar"?  It
seems to have the required functionality to replace and print entries.

I, for one, would be willing to have 3 Meg of pathalias data if it
would result in more up to date maps.  (I can't seem to get a entry
published in is less than 6 months.)  Any site that can't afford the
extra disk has several alternatives.  One is to grep out the '^#'
lines.  These are not used by pathalias and constitute 50% of the
disk storage!  This would cut their storage back to less than the
current method though they would still use more inodes.  Or they could
run an abbreviated pathalias and specify a nearby smart mailer.

I would suggest that we test breaking up the maps by splitting just the
d.* maps into their individual entries.  This represents an expansion
from 44 to 163 files and shouldn't break anybody.  Also, the domain
sites are paying for their entry, they should get quicker updating.
This way "d.olivetti.com" could be distributed as soon as it is
received instead of waiting to bundle it with the other 30 d.usa.ca.2
entries.

					Jerry Aguirre
					Systems Administration
					Olivetti ATC