<html><body><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div>There are two concerns in the usage of libgfapi which have been present from day one, but now<br></div><div>with new users of libgfapi its a necessity to fix these:<br></div><div><br></div><div>1. When libgfapi is used by the GlusterFS internal xlators, 'THIS' gets overwritten:<br></div><div> Eg: when snapview-server creates a new fs instance for every snap that is created.<br></div><div> Currently any libgfapi calls inside the xlator overwrites the THIS value to contain glfs-master(gfapi xlator).<br></div><div> Hence after the api exits, any further code in the parent xlator referring to THIS will refer</div><div> to the glfs-master(gfapi xlator).<br></div><div><br></div><div> Proposed solutions:<br></div><div> - Store and restore THIS in every API exposed by libgfapi, patch for the same can be found at <a href="http://review.gluster.org/#/c/9797/">http://review.gluster.org/#/c/9797/</a><br></div><div> - Other solution suggested by Niels was to not have internal xlators calling libgfapi and<br></div><div> move the core functionality to libglusterfs. But even with this the nested mount/ctx issue can still exist.<br></div><div><br></div><div>2. When libgfapi APIs are called by the application on a fs object, that is already closed(glfs_fini()'ed):<br></div><div> Ideally it is the applications responsibility to take care, to not do such things. But its also good<br></div><div> to not crash libgfapi when such ops are performed by the application.<br></div><div> We have already seen these issues in snapview server.<br></div><div><br></div><div> Proposed Solutions/workarounds:<br></div><div> - Do not free the fs object(leaks few bytes) have a state bit to say valid or invalid. In every API check<br></div><div> for the fs validity before proceeding. Patch for same @http://review.gluster.org/#/c/9797/<br></div><div> - As suggested by Niels, have a fs global pool which tracks allocated/freed fs objects.<br></div><div> - Have the applications fix it, so that they do not call fops on closed fs object(unmounted fs).<br></div><div> This mandates multithreaded/asynchronous applications to have some synchronization mechanism.<br></div><div><br></div><div>Please let me know your comments on the same.<br></div><div><br></div><div>Regards,<br></div><div>Poornima<br></div></div></body></html>