[OpenAFS-devel] Adding an "estimate" function to vlserver

[Neulinger, Nathan]

As long as the rx interface is defined to include space for returning
the information, the actual calculation could always be added later. Key
is to make sure there is room available for expansion so that we don't
have to have incompatible api calls.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Mitch Collinsworth [mailto:mitch@ccmr.cornell.edu]=20
> Sent: Friday, April 04, 2003 11:58 AM
> To: Neulinger, Nathan
> Cc: openafs-devel@openafs.org
> Subject: RE: [OpenAFS-devel] Adding an "estimate" function to=20
> vlserver=20
>=20
>=20
>=20
> On Fri, 4 Apr 2003, Neulinger, Nathan wrote:
>=20
> > I agree with Mitch that adding the new command would be the=20
> best way to
> > go here. However, it isn't really an "estimate", since it=20
> should be able
> > to determine an exact size that the dump will be.
> >
> > Perhaps "vos size". I'd say dumpsize, but that would likely cause
> > problems with command abbreviation.
>=20
> Good point.  'Estimate' is amanda lingo.  Our code does=20
> determine exact
> size, so yes 'vos size' makes more sense.  Thanks for=20
> pointing this out.
>=20
>=20
> > Might be worth considering whether to add some options to=20
> the command to
> > maybe consider other sizing information.
> >
> > For example:
> >
> > 	vos size -id volname -from X -dump      size of the dump, make
> > from optional to allow sizing an incremental dump as well...
> > 	vos size -id volname -files       return number of files/dirs on
> > volume
> >       vos size -id volume -from X -files      return number of
> > files/dirs on volume changed in that incremental
> >       vos size -id volume -from X -overhead     return amount of
> > "wasted" space in dump due to dumping of directory=20
> information. In some
> > volumes on our server, this can be quite considerable for=20
> volumes that
> > have a large directory structure, but only a tiny amount of file
> > changes.
>=20
> Agree.  We do need the -from for our project, and had already=20
> coded that
> feature in our standalone utility.  These other options sound easy
> enough to add.  The programmer who did the original work a=20
> couple summers
> ago is back with us for a (very) short time and I want to=20
> move the amanda
> project forward as much as possible while we have him.  Once the basic
> stuff is done I'll ask him to add these if there is still time.
>=20
>=20
> > -- Nathan
>=20
> -Mitch
>=20