[Gluster-devel] Improving real world performance by moving files closer to their target workloads

Martin Fick mogulguy at yahoo.com
Mon Jun 2 16:33:16 UTC 2008

--- Derek Price <derek at ximbiot.com> wrote:
> 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 agree, I was going on the assumption that this would
potentially be a common case for Luke and that was why
he brought it up, but again that was my assumption, it
may not be the case.

> 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.

Except that as I pointed out in my other email, I do
not think that this would actually make reading any
better than today's caching translator, and if so,
then simply improving the caching translator should
suffice.  And, it would make writes much more
complicated and in fact probably slower than what
unify does today.  So where is the gain?



More information about the Gluster-devel mailing list