On Wednesday, January 05, 2005 12:39:33 -0500 Mitch Collinsworth <[EMAIL PROTECTED]> wrote:
On Wed, 5 Jan 2005, Jeffrey Hutzelman wrote:
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.
Thank you! This is what I'm concerned about. Our tools to backup AFS using Amanda parse the dump file format in order to generate an index of files. If the volume headers are kept uncompressed then this should not be a problem.
Hm. Stage parses the dump header to get timestamps and the like, but we haven't gotten around to file indexing yet. Creating a file index would require parsing the (presumably compressed) directory vnodes.
Of course the other solution would be an interface that does the dump file parsing and presents a consistent API for external tools to use. Then we wouldn't need to be on guard against file format changes. :-)
/afs/cs.cmu.edu/project/systems-jhutz/dumpscan
But I really should do a formal release one of these days.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
