Martin Fick wrote:
Again, Luke suggested improving the current unify translator with migration. Do you think that this would improve it? The answer I suspect has to do with your workload, thus the suggestion for multiple migration schedulers. Surely some workloads will benefit from this. If you have workloads (even suggested imaginary ones) that will not be improved by this strategy, by all means, bring them up. If you have workloads that will actually be hurt by the strategy, of course, bring those up first! I suspect that some workloads may indeed be hurt by this and may result in "migration thrashing" where a file keeps bouncing from node to node -> back to designing good schedulers with good heuristics.
I think the unify migrator would probably help at least a little in the case where one node tends to use a file much more often than other nodes, but how likely is this to be the case? When this isn't the case, or when the node that tends to use the file most varies from day to day or moment to moment, I think you will see the migration thrashing issue you mentioned. I think the AFR migrator we were discussing, where copies of files may be kept in several locations, would be useful in the more general case where a number of machines tended to read and write a file regularly. Of course, I can't argue with you over which will be easier to implement. Regards, Derek -- Derek R. Price Solutions Architect Ximbiot, LLC <http://ximbiot.com> Get CVS and Subversion Support from Ximbiot! v: +1 248.835.1260 f: +1 248.246.1176
