[OpenAFS-devel] Patches for Openafs compression support

[Jeffrey Hutzelman]

On Wednesday, January 05, 2005 09:00:59 +0100 Harald Barth 
<haba@pdc.kth.se> wrote:

> +#define        VOLRESTORE_Z            65535
> +#define        VOLFORWARD_Z            65534
> +#define        VOLDUMP_Z               65533
> +#define        VOLFORWARDMULTIPLE_Z    65532
> ...
> +proc RestoreZ(
> +  IN afs_int32 toTrans,
> +  IN afs_int32 flags,
> +  IN struct restoreCookie *cookie,
> +  IN afs_int32 compress,
> +  IN afs_int32 level
> +) split = VOLRESTORE_Z;
>
> Do we want to implement compression as seperate calls for every thing
> that we want to compress or should we be able to switch it on/off
> like encryption?

Actually, what I'd like to see is an extension to the dump file format to 
allow for compressed dumps.  In this model, "new" volservers would 
automatically generate compressed dumps if the feature was enabled, and 
would always be able to accept either kind of dump.  No new RPC's would be 
added (*), and no changes to any clients would be required.  The compressed 
part of the dump should begin with the vnodes, leaving the dump and volume 
headers uncompressed for tools which expect to be able to parse these.

(*) It may be worthwhile at some point to add a get-capabilities call so 
that a volserver doing a vol-forward can tailor the dump it generates to 
the capabilities of the receiving volserver.  However, this is not required 
- just don't turn on the generate-compressed-dumps feature until all of the 
servers in your cell are capable of receiving them.



> Remind me: Did we write something down on how to agree on new calls?

You send a request to registrar@grand.central.org describing the new RPC(s) 
you want, and I assign procedure numbers and add them to the registry. 
IIRC we discussed this and the use of 0x10000 as the base for coordinated 
calls at the first hackathon.

The numbers shown above are not coordinated, and will never be assigned by 
the registrar.  They lie in a region that was originally reserved to avoid 
conflicts in case IBM decided not to play the coordination game.  They 
should not be used in released code; instead, if we are going to use this 
approach, numbers should be obtained via mail to the registrar.


> +/* Start a dump and send it to multiple places simultaneously.
> + * If this returns an error (eg, return ENOENT), it means that
> + * none of the releases worked.  If this returns 0, that means
> + * that one or more of the releases worked, and the caller has
> + * to examine the results array to see which one(s).
> + * This will only do EITHER incremental or full, not both, so it's
> + * the caller's responsibility to be sure that all the destinations
> + * need just an incremental (and from the same time), if that's
> + * what we're doing.
> + */
>
> This may be good but not "compression" ;-)

The comment you quote wasn't added; it just moved as a consequence of 
abstracting out the base dump operation from AFSVolDumpVolume to allow for 
creation of the _Z version.

-- Jeff