Re: [Gluster-devel] Proposal: GlusterFS Quattro

[Anand Avati]

On Fri, Mar 7, 2014 at 11:56 AM, Jeff Darcy <address@hidden> wrote:

> Given the background, it only makes sense to retain the guiding principles of
> the feedback, and reconcile the changes proposed to management layer in the
> two proposals and retain the scope of 4.x to management changes.

> Thoughts?

I think we need to take a more careful look at dependencies between various
items before we decide what should be in 4.0 vs. earlier/later.  For example,
several other features depend on being able to subdivide storage that the
user gives us into smaller units.  That feature itself depends on multiplexing
those smaller units (whether we call them s-bricks or something else) onto
fewer daemons/ports.  So which one is the 4.0 feature?  If we have a clear
idea of which parts are independent and which ones must be done sequentially,
then I think we'll be better able to "draw a line" which separates 3.x from
4.x at the most optimal point.

The "brick model" is probably the borderline item which touches upon both management layer and data layer to some extent. Decreasing the number of processes/ports in general is a good thing, and to that end we need our brick processes to be more flexible/dynamic (able to switch a graph on the fly, add a new export directory on the fly etc.) - which is completely lacking today. I think, by covering this piece (brick model) we should be mostly able to classify rest of the changes into "management" vs "data path" in a more clear way. That being said we still need a low level design of how to make the brick process more dynamic (though it is mostly a matter of just "getting it done")

Avati