Jay,
there are few parts to consistency.
- 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
- 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.
- 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.
HTH
Avati
On Wed, Feb 5, 2014 at 8:31 AM, Jay Vyas <jayunit100@xxxxxxxxx> wrote:
Hi gluster !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?
Thanks!
This is important to us in hadoopland.
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
