AFR load-balancing (was:Re: [Gluster-devel] Full bore.)

[Jerker Nyberg]

On Sat, 17 Nov 2007, Krishna Srinivas wrote:

> Actually, if a file is read from a node, if another application opens and
> reads it, reads should be done from the same node to take advantage
> of the server side io-caching and server side kernel caching. As of now
> we just hash the inode number to decide on the read-node, a plain and
> simple mechanism.
>
> (We can think about schedulers similar to the ones in unify, but they can't
> be re-used, but conceptually they are similar, unify would schedule based
> on the disk space and afr would schedule based on CPU utilization.
> In future versions though. Suggestions welcome :) )

Just for letting you know, this works as intended. However, In my case I'm 
when testing out the read balancing I am afr'ing over seven servers and 
reading the a single file from all the server. If I could stripe the reads 
from the servers, or even getting the client to choose another server than 
the first I would get happy, this way I could scale the throughput when 
when adding more servers. (But I could just let the clients read from them 
selves in the mean time.)

Writes are slow, (since a client need to write to all servers, but perhaps 
is it possible to stack the afrs on the server side and let the servers do 
the replicating when writing... Hmmm...)

When suggestions are welcome, a parity translator (RAID5 RAID6) on a file 
level (self-healing) would also be nice. I tried to look at the stripe 
code to figure out what is happening but I didn't understand much. :) (I 
might be having some time this spring to look at something like that, but 
that particular project is probably too much for me.)

--jerker