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

Neulinger, Nathan nneul@umr.edu
Fri, 4 Apr 2003 10:04:53 -0600


I agree with Mitch that adding the new command would be the best way to
go here. However, it isn't really an "estimate", since it 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

Might be worth considering whether to add some options to 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...=20
	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 information. In some
volumes on our server, this can be quite considerable for volumes that
have a large directory structure, but only a tiny amount of file
changes.

-- 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 9:48 AM
> To: Joseph V Moss
> Cc: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] Adding an "estimate" function to=20
> vlserver=20
>=20
>=20
>=20
> On Thu, 3 Apr 2003, Joseph V Moss wrote:
>=20
> > If you're modifying vos to add a new command, couldn't you=20
> just code up
> > the change so that 'vos dump -estimate' sends the new RPC=20
> rather than
> > a modified version of the existing dump RPC call?
>=20
> Good question.  And exactly what I asked when this dilema was brought
> to my attention.  It turns out that because of the way the code is
> currently structured, doing this would require significant=20
> restructuring.
> The RPC opcodes and parameters are rather strictly tied to the vos
> command suite syntax.  A bit hard to explain in words but if you look
> at the code the problem is immediately obvious.  We didn't look at
> them but my guess is the other command suites are probably coded
> similarly.  I'm not really interested in untangling the coding style,
> just adding one new feature.
>=20
>=20
> > Or as a different possible interface, how about 'vos=20
> examine -dumpsize' to
> > get it to show the size you're looking for rather than the=20
> one it shows currently.
>=20
> This would have the same backwards compatibility problem as
> 'vos dump -estimate'.
>=20
> -Mitch
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>=20