gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gluster-devel] Bricks as first-class objects


From: Jeff Darcy
Subject: [Gluster-devel] Bricks as first-class objects
Date: Tue, 22 Jan 2013 12:46:14 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]