----- Original Message ----- > From: "Jeff Darcy" <jdarcy@xxxxxxxxxx> > To: "Rajesh Joseph" <rjoseph@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Wednesday, April 8, 2015 1:53:38 AM > Subject: Re: metdata-volume for gluster > > > In gluster 3.7 multiple features (Snapshot scheduler, NFS Ganesha, Geo-rep) > > are planning to use > > additional volume to store metadata related to these features. This volume > > needs to be manually > > created and explicitly managed by an admin. > > > > I think creating and managing these many metadata volume would be an > > overhead > > for an admin. Instead > > of that I am proposing to have a single unified metata-volume which can be > > used by all these features. > > > > For simplicity and easier management we are proposing to have a pre-defined > > volume name. > > If needed this name can be configured using a global gluster option. > > > > Please let me know if you have any suggestions or comments. > > Do these metadata volumes already exist, or are they being added to designs > as we speak? There seem to be a lot of unanswered questions that suggest > the latter. For example... This is being added as we speak. > > * What replication level(s) do we need? What "performance" translators > should be left out to ensure consistency? Ideally here we need greater number of replication but since we only support x3 replication we would be recommending x3 replication. It is still under design therefore we have not finalized on the performance translators part. But I think we can leave out of most of the performance translators for this. > > * How much storage will we need? How will it be provisioned and tracked? As I said earlier in the current release it would be done manually by system administrators. And therefore managed by them. In the subsequent release we can work towards a management framework. > > * What nodes would this volume be hosted on? Does the user have to > (or get to) decide, or do we decide automatically? What happens as > the cluster grows or shrinks? > > * How are the necessary daemons managed? From glusterd? What if we > want glusterd itself to use this facility? > > * Will there be an API, so the implementation can be changed to be > compatible with similar facilities already scoped out for 4.0? > > I like the idea of this being shared infrastructure. It would also be > nice if it can be done with a minimum of administrative overhead. To > do that, though, I think we need a more detailed exploration of the > problem(s) we're trying to solve and of the possible solutions. I agree that we should do this with minimum administrative overhead, but it really require more detailed investigation and a thorough design. we have started exploring in that direction, but we have no workable solution as of now. My current proposition is to just reduce the number of manual metadata-volume required to run gluster. Thanks & Regards, Rajesh _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
