After Ben England found that reads were all going to a single subvolume in 3.2.5, I looked into this area of the code.  The earlier "first to respond" approach seems to have been abandoned, but the "round robin" approach used in 3.3 does an inadequate job of avoiding hot spots.  Consider an application where each client opens a hundred files in the same sequence.  Because of the way the round-robin works, these two clients have a 50% chance of their read_child_rr values being in sync and *staying in sync* throughout the entire set of opens.

A better solution would be to have the selection of a read child be random.  Better still, it could be based on a hash of the gfid (to distribute reads among files but ensure consistent reads for a single file) or of the gfid plus some client identifier (to provide full distribution even for a single file).  The patch will be forthcoming as soon as I have a bug number.