<br><br><div class="gmail_quote">On Tue, Jan 22, 2013 at 9:46 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
gluster brick create mybrick server1:/some/random/path<br>
<br>
OK, big deal. Now it gets a bit more interesting.<br>
<br>
gluster brick set mybrick storage-type reallyfast<br>
<br>
Still doesn't seem all that useful, eh?<br>
<br>
gluster brick set otherbrick storagetype reallyfast<br>
gluster volume set placement-pattern '*.mp4:reallyfast'<br>
<br>
This is from <a href="http://review.gluster.org/#change,4410" target="_blank">http://review.gluster.org/#<u></u>change,4410</a> 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.<br>
<br>
gluster brick stop mybrick<br>
gluster brick move mybrick server2:/another/path<br>
gluster brick start mybrick<br>
<br>
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.<br>
<br>
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?<br></blockquote><div><br>
</div><div><br></div><div>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.)</div>
<div><br></div><div>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.)</div>
<div><br></div><div>Avati</div></div>