[Gluster-devel] Proposal: GlusterFS Quattro

[Anand Avati]

On Fri, Mar 7, 2014 at 11:56 AM, Jeff Darcy <jdarcy at redhat.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140307/d5dc039a/attachment-0001.html>