+#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 [EMAIL PROTECTED] 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
_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
