<div dir="ltr"><div>Thanks avati. <br><br>Just for context in case others are moving to libgfapi: <br><br>On our end, we want to improve small file performance on WRITES, without sacrificing consistency on READS.<br><br></div>
<div>Im not sure if thats possible but we can look deeper into the translators you mentioned, possibly as an answer to get that kind of behaviour. <br><br></div><div>Is there a simple set of parameters stored somewhere (i.e. in /etc/... or something like that) that can guide LibGFAPI behaviour, similar to the mount "-o" options which we pass to the FUSE mount? <br>
</div><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 5, 2014 at 5:26 PM, Anand Avati <span dir="ltr"><<a href="mailto:avati@gluster.org" target="_blank">avati@gluster.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jay,<div>there are few parts to consistency.</div><div><br></div><div>- file data consistency: libgfapi by itself does not perform any file data caching, it is entirely dependent on the set of translators (write-behind, io-cache, read-ahead, quick-read) that are loaded, and the effect of those xlators is same in both FUSE and libgfapi</div>
<div><br></div><div>- inode attribute/xattr (metadata) consistency: (the thing you tune with --attribute-timeout=N in FUSE) again libgfapi does not perform any meta data caching and depends whether you have loaded md-cache/stat-prefetch translator.</div>
<div><br></div><div>- entry consistency: this is remembering dentries (e.g: "the name 'file.txt' under directory having gfid 12345 maps to file with gfid 48586", or "the name 'cat.jpg' under directory having gfid 456346 does not exist or map to any inode" etc.) and is similar to the thing you tune with --entry-timeout=N in FUSE. libgfapi remembers such dentries in an optimistic way such that the path resolver re-uses the knowledge for the next path resolution call. However the last component of a path is always resolved "uncached" (even if entry is available in cache) and upon any ESTALE error the entire path resolution + fop is re-attempted in a purely uncached mode. This approach is very similar to the retry based optimistic path resolution in the more recent linux kernel vfs.</div>
<div><br></div><div>HTH</div><div>Avati</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Feb 5, 2014 at 8:31 AM, Jay Vyas <span dir="ltr"><<a href="mailto:jayunit100@gmail.com" target="_blank">jayunit100@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Hi gluster !<br><br></div>How does libgfapi enforce FileSystem consistency? Is it better than doing this than exsiting FUSE mounts which require the *timeout parameters to be set to 0?<br>
<br>Thanks!<br>
<br>This is important to us in hadoopland.<span><font color="#888888"><br clear="all"><div><div><br>-- <br>Jay Vyas<br><a href="http://jayunit100.blogspot.com" target="_blank">http://jayunit100.blogspot.com</a>
</div></div></font></span></div>
<br></div></div>_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br></blockquote></div><br></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Jay Vyas<br><a href="http://jayunit100.blogspot.com" target="_blank">http://jayunit100.blogspot.com</a>
</div>