[Gluster-devel] Bricks as first-class objects

[Anand Avati]

On Tue, Jan 22, 2013 at 9:46 AM, Jeff Darcy <jdarcy at redhat.com> wrote:

> 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<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?
>


This would also be a nice way to implement rack awareness by tagging bricks
with racknumbers, and using that for the logic to re-group bricks into
replica sets at the time of volume create (rather than depending on the
order of specification.)

It would also "nicely" solve the problem of how to deal with data of
deleted volumes. A "gluster brick delete [force]" can do the cleanup of
xattrs on the brick directory (and optionally delete all the data, if
forced.)

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130122/2a11ab81/attachment-0001.html>