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 at gmail.com> 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.
>
> --
> Jay Vyas
> http://jayunit100.blogspot.com
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140205/3c5a18df/attachment.html>