[Gluster-devel] Volume management proposal (4.0)

Krishnan Parthasarathi kparthas at redhat.com
Fri Dec 19 03:26:53 UTC 2014


> 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.

The above persistence scheme makes querying for volumes affected by a change
to a given volume, linear in length of path from given volume to the primary volume,
the 'root', in the graph of volumes. The alternative would involve going
through every volume to check if the volume changed affects it. This is linear
in no. of volumes in the cluster. This computational complexity makes me favour
storing child-parent relationships in the secondary volumes. The only down-side
is that we need to 'lock-down' secondary volumes from being modified. I don't
have a way to measure the effect (yet) this would have on (concurrent) modifications
on secondary volumes of a given primary volume.
> 
> * 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.

This makes sense.



More information about the Gluster-devel mailing list