Hi Rajesh, Couple of questions more. 1. How is metadata-volume automount on reboot of node is take care? Is it advised to add it in /etc/fstab? 2. How does it get mounted on peer add (node) case? Thanks and Regards, Kotresh H R ----- Original Message ----- > From: "Rajesh Joseph" <rjoseph@xxxxxxxxxx> > To: "Jeff Darcy" <jdarcy@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Wednesday, April 8, 2015 4:11:24 PM > Subject: Re: metdata-volume for gluster > > > > ----- 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 > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
