> Persisting the volume relationships in the volume info file > (i.e, /var/lib/glusterd/vols/VOLNAME/info) is a good idea. With this we could > contain volume (relationship) management within the management plane. > Do you have ideas on how to persist volume relationships? It seems simplest to store child-parent relationships (one to one) instead of parent-child relationships (one to many). Based on that, I looked at some info files and saw that we're already using "parent_volname" for snapshot stuff. Maybe we need to change terminology. Let's say that we use "part-of" in the info file. * Create a new string-valued glusterd_volinfo_t.part_of field. * This gets filled in from glusterd_store_update_volinfo along with everything else from the info file. * When a composite volume is created, its component volumes' info files are rewritten. * When a component volume is modified, use the part_of field to find its parent. We then generate the fully-resolved client volfiles before and after the change and compare for differences. * If we find differences in the parent, process the change as though it had been made on the parent (triggering graph switches etc.) and then use the parent's part_of field to repeat the process one level up. I don't think we need to do anything for server-side-only changes, since those will already be handled (e.g. starting new bricks) by the existing infrastructure. However, things like NFS and quotad might need to go through the same process outlined above for clients. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
