Also inline. ----- Original Message ----- > The scalability factor I mentioned simply had to do with the core > infrastructure (depending on very basic mechanisms like the epoll wait > thread, the entire end-to-end flow of a single fop like say, a lookup() > here). Even though this was contained to an extent by the introduction > of the io-threads xlator in snapd, it is still a complex path that is > not exactly about high performance design. That wasn't the goal to begin > with. Yes, if you get rid of the daemon it doesn't have those issues ;). > I am not sure what the linear range versus a non-linear one has to do > with the design? Maybe you are seeing something that I miss. A random > gfid is generated in the snapview-server xlator on lookups. The > snapview-client is a kind of a basic redirector that detects when a > reference is made to a "virtual" inode (based on stored context) and > simply redirects to the snapd daemon. It stores the info returned from > snapview-server, capturing the essential inode info in the inode context > (note this is the client side inode we are talking abt). That last note, is merely a warning against changing the properties of the UUID generator, please ignore it. > In the daemon there is another level of translation which needs to > associate this gfid with an inode in the context of the protocol-server > xlator. The next step of the translation is that this inode needs to be > translated to the actual gfid on disk - that is the only on-disk gfid > which exists in one of the snapshotted gluster volumes. To that extent > the snapview-s xlator needs to know which is the glfs_t structure to > access so it can get to the right gfapi graph. Once it knows that, it > can access any object in that gfapi graph using the glfs_object (which > has the real inode info from the gfapi world and the actual on-disk gfid). No daemon! SCRAP IT! Throw it in the bin, and don't let it climb back out. What you are proposing: random gfid -> real gfid ; as the mapping the daemon must maintain. What I am proposing: real gfid + offset -> real gfid ; offset is a per snapshot value, local to the client. Because the lookup table is now trivial, a single integer per snapshot. You don't need all that complex infrastructure. Thanks, -Ira _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
