This is a few short notes on redundant storage in glusterfs.

Approach 1:

		Unify with switch scheduler
               /    |    \
              /     |     \
             /      |      \
           AFR     AFR     AFR
          /  |     / \     |  \
         B1 B2    B3 B4    B5  B6


	For a new file stored at the top, unify picks a single
AFR to take it, and that AFR stores it in all (in this picture, 2) of
it's sub-bricks.  As an example, the file might end up on bricks 3 and
4.
	Picture it as unionfs on top of file-level raid.
	Adding new AFR's expands capacity but doesn't improve redundancy.

	Pros:   

	Cons: Loss of one AFR (network outage?) means data under it is
inaccessible.




Approach 2

		   AFR
               /    |    \
              /     |     \
             /      |      \
          Unify   Unify   Unify
          /  |     / \     |  \
         B1 B2    B3 B4    B5  B6


	When a new file is stored in the AFR at the top, it's handed to
each of the Unify's, each of which pick a single underlying brick for
storing the file.  In this example, a file might end up on bricks 2, 4,
and 5.

	Picture it as file-level raid on top of mutiple union
filesystems.

	Cons: Adding more underlying unify bricks does not expand
capacity, only redundancy.


Approach 3

              Translator
              / / | \ \
             / /  |  \ \
            /  |  |  |  \
          B1  B2 B3  B4  B5


	Translator sends each file to N bricks, more than 1 but less
than 5.  

	Pros: capacity expands by adding bricks.  Redundancy expands by
changing N in client config files.

	Unify's "switch" scheduler allows one to manually specify
multiple bricks for different filespecs (*.jpg stored on bricks 1 and 4,
*.html stored on just brick 3, and everything else on bricks 2 and 5). 
This approach comes closest to the above, but doesn't take advantage of
the ALU scheduler that can pick which underlying brick to use based on
free space, load, etc.





Notes:

	AFR option "read-volume" allows you to specify the preferred
brick for reads.  If not forced by this option, documentation says the
reads _should_ be spread out among the underlying bricks, but one person
on the glusterfs irc channel thought this has not been successfully
implemented.