Re: Improving real world performance by moving files closer to their target workloads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- Derek Price <derek@xxxxxxxxxxx> 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?

-Martin



      




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux