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
