<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 8, 2014 at 11:48 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> client graph is not dynamically modified. the snapview-client and<br>
> protocol/server are inserted by volgen and no further changes are made on<br>
> the client side. I believe Anand was referring to " Adding a protocol/client<br>
> instance to connect to protocol/server at the daemon" as an action being<br>
> performed by volgen.<br>
<br>
</div>OK, so let's say we create a new volfile including connections for a snapshot<br>
that didn't even exist when the client first mounted. Are you saying we do<br>
a full graph switch to that new volfile? </blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> That still seems dynamic. Doesn't<br>
that still mean we need to account for USS state when we regenerate the<br>
next volfile after an add-brick (for example)? One way or another the<br>
graph's going to change, which creates a lot of state-management issues.<br></blockquote><div><br></div><div>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.</div>
<div><br></div></div><br></div></div>