[Gluster-devel] Bricks as first-class objects

Jeff Darcy jdarcy at redhat.com
Tue Jan 22 17:46:14 UTC 2013


Right now, bricks are sort of second-class objects.  They're host:path pairs 
that sort of only exist within the context of the volumes where they're used, 
and they don't have any other attributes.  What if they did have their own 
identity and attributes?  Consider the following:

	gluster brick create mybrick server1:/some/random/path

OK, big deal.  Now it gets a bit more interesting.

	gluster brick set mybrick storage-type reallyfast

Still doesn't seem all that useful, eh?

	gluster brick set otherbrick storagetype reallyfast
	gluster volume set placement-pattern '*.mp4:reallyfast'

This is from http://review.gluster.org/#change,4410 which is what inspired this 
line of thinking.  Now things get much more interesting.  We can essentially 
put bricks into "placement groups" and use those to give users more control 
over where their files go.  Some of our competitors already do this.  ;) 
Here's another trick.

	gluster brick stop mybrick
	gluster brick move mybrick server2:/another/path
	gluster brick start mybrick

Pretty obvious what happened here, isn't it?  The user wants to move a brick 
physically from server1 to server2.  This way seems very intuitive, and because 
we retain the brick's identity/attributes throughout it's very easy for us to 
do the right thing - in contrast to the arcane details of current 
replace-brick.  Being able to start/stop individual bricks in a fully 
integrated way will be very handy for testing too.

We could also do top/latency on individual bricks this way some day, and all 
sorts of other tricks too.  It doesn't even seem like it would be all that 
complicated to implement.  Any thoughts?






More information about the Gluster-devel mailing list