[Gluster-devel] Volume management proposal (4.0)
Krishnan Parthasarathi
kparthas at redhat.com
Thu Dec 18 12:36:10 UTC 2014
> > 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?
More information about the Gluster-devel
mailing list