On Thursday 06 January 2005 19.40, Jeffrey Hutzelman wrote: > I'm aware of how volume moves work. It is not the case that a special > VolForwardZ would be necessary to control whether moves were done using > compression. Instead, I would expect the source volserver (the one to > which you make the VolForward call) to determine the capabilities of each > target server and behave appropriately, without user intervention. Again, > the client should not need to know or care whether compressed dumps are > being used. > > Note that this mechanism is not strictly required -- correct behaviour can > be obtained simply by not turning on the generation of compressed dumps > until all servers in the cell are new enough to support them. However, I > expect that transition to using the new functionality would be eased by > allowing AFSVolForward to do automatic capability detection. This would, > for example, allow a site to deploy a test server using the new compression > code, and easily move volumes onto and off of the test server.
I have the following problems/questions with this approach: - is it good to use the same compression level for storing and transmitting data? - is it good to specify the same compression settings (whether to compress, and level) for a whole volserver process? For example: when some of the volumes on that server has RO sites with fast connection, and there are some others with slow connection to RO sites? (Perhaps it would require a new config file or database where a table describes for each volume whether to use compression and level) - I don't understand how do you mean the auto-detection. Could you explain in more details how/when/where to deploy the test server? > The standard approach is to request and receive new procedure numbers > before submitting a patch, rather than submitting a patch which uses > made-up or private-use numbers. This prevents the unfortunate situation in OK. I will request after the design accepted (if needed). Thanks. Peter _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
