<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 8, 2014 at 4:45 AM, Ira Cooper <span dir="ltr"><<a href="mailto:ira@redhat.com" target="_blank">ira@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also inline.<br>
<div class=""><br>
----- Original Message -----<br>
<br>
> The scalability factor I mentioned simply had to do with the core<br>
> infrastructure (depending on very basic mechanisms like the epoll wait<br>
> thread, the entire end-to-end flow of a single fop like say, a lookup()<br>
> here). Even though this was contained to an extent by the introduction<br>
> of the io-threads xlator in snapd, it is still a complex path that is<br>
> not exactly about high performance design. That wasn't the goal to begin<br>
> with.<br>
<br>
</div>Yes, if you get rid of the daemon it doesn't have those issues ;).<br>
<div class=""><br>
> I am not sure what the linear range versus a non-linear one has to do<br>
> with the design? Maybe you are seeing something that I miss. A random<br>
> gfid is generated in the snapview-server xlator on lookups. The<br>
> snapview-client is a kind of a basic redirector that detects when a<br>
> reference is made to a "virtual" inode (based on stored context) and<br>
> simply redirects to the snapd daemon. It stores the info returned from<br>
> snapview-server, capturing the essential inode info in the inode context<br>
> (note this is the client side inode we are talking abt).<br>
<br>
</div>That last note, is merely a warning against changing the properties of the UUID generator, please ignore it.<br>
<div class=""><br>
> In the daemon there is another level of translation which needs to<br>
> associate this gfid with an inode in the context of the protocol-server<br>
> xlator. The next step of the translation is that this inode needs to be<br>
> translated to the actual gfid on disk - that is the only on-disk gfid<br>
> which exists in one of the snapshotted gluster volumes. To that extent<br>
> the snapview-s xlator needs to know which is the glfs_t structure to<br>
> access so it can get to the right gfapi graph. Once it knows that, it<br>
> can access any object in that gfapi graph using the glfs_object (which<br>
> has the real inode info from the gfapi world and the actual on-disk gfid).<br>
<br>
</div>No daemon! SCRAP IT! Throw it in the bin, and don't let it climb back out.<br>
<br>
What you are proposing: random gfid -> real gfid ; as the mapping the daemon must maintain.<br>
<br>
What I am proposing: real gfid + offset -> real gfid ; offset is a per snapshot value, local to the client.<br>
<br>
Because the lookup table is now trivial, a single integer per snapshot. You don't need all that complex infrastructure.<br></blockquote><div><br></div><div>The purpose for the existence of the daemon is two:</div><div>
<br></div><div>- client cannot perform privileged ops to glusterd regarding listing of snaps etc.</div><div><br></div><div>- limit the total number of connections coming to bricks. If each client has a new set of connections to each of the snpashot bricks, the total number of connections in the system will become a function of the total number of clients * total number of snapshots.</div>
<div><br></div><div>gfid management is something completely orthogonal, we can use the current random gfid or a more deterministic one (going to require a LOT more changes to make gfids deterministic, and what about already assigned ones, etc.) whether the .snap view is generated on client side or server side.</div>
</div></div></div>