Re: [Gluster-devel] User-serviceable snapshots design

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






On Thu, May 8, 2014 at 11:48 AM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:
> client graph is not dynamically modified. the snapview-client and
> protocol/server are inserted by volgen and no further changes are made on
> the client side. I believe Anand was referring to " Adding a protocol/client
> instance to connect to protocol/server at the daemon" as an action being
> performed by volgen.

OK, so let's say we create a new volfile including connections for a snapshot
that didn't even exist when the client first mounted.  Are you saying we do
a full graph switch to that new volfile?

No graph changes either on client side or server side. The snap-view-server will detect availability of new snapshot from glusterd, and will spin up a new glfs_t for the corresponding snap, and start returning new list of "names" in readdir(), etc.
 
 That still seems dynamic.  Doesn't
that still mean we need to account for USS state when we regenerate the
next volfile after an add-brick (for example)?  One way or another the
graph's going to change, which creates a lot of state-management issues.

No volfile/graph changes at all. Creation/removal of snapshots is handled in the form of a dynamic list of glfs_t's on the server side.


_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users

[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux