> > IIUC, (E) describes that primary volume file would be generated with all > > secondary volume references resolved. Wouldn't that preclude the > > possibility > > of the respective processes discovering the dependencies? > > That's not entirely clear. The *volfiles* might not contain the necessary > information, depending on exactly when we resolve references to other > volumes - e.g. at creation, volfile-fetch, or even periodically. However, I assumed from (E) that volfiles of the primary volumes were generated at the time of volume creation, where all references to constiuent secondary volumes would be resolved. Yes, there are other places where this could be done giving processes a chance to detect changes deeper in the graph (of volumes). > the *info* files from which the volfiles are generated would necessarily > include at least the parent-to-child links. We could scan all info files > during any configuration change to find such dependencies. Even better, > we could also store the child-to-parent links as well, so when we change > X we *immediately* know whether that might affect a parent volume. 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? _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
