[Gluster-devel] Feature proposal - FS-Cache support in FUSE
avati at gluster.org
Tue Sep 2 15:20:35 UTC 2014
On Mon, Sep 1, 2014 at 6:07 AM, Vimal A R <arvimal at yahoo.in> wrote:
> Hello fuse-devel / fs-cache / gluster-devel lists,
> I would like to propose the idea of implementing FS-Cache support in the
> fuse kernel module, which I am planning to do as part of my UG university
> course. This proposal is by no means final, since I have just started to
> look into this.
> There are several user-space filesystems which are based on the FUSE
> kernel module. As of now, if I understand correct, the only networked
> filesystems having FS-Cache support are NFS and AFS.
> Implementing support hooks for fs-cache in the fuse module would provide
> networked filesystems such as GlusterFS the benefit of a client-side
> caching mechanism, which should decrease the access times.
If you are planning to test this with GlusterFS, note that one of the first
challenges would be to have persistent filehandles in FUSE. While GlusterFS
has a notion of a persistent handle (GFID, 128bit) which is constant across
clients and remounts, the FUSE kernel module is presented a transient LONG
(64/32 bit) which is specific to the mount instance (actually, the address
of the userspace inode_t within glusterfs process - allows for constant
time filehandle resolution).
This would be a challenge with any FUSE based filesystem which has
persistent filehandles larger than 64bit.
> When enabled, FS-Cache would maintain a virtual indexing tree to cache the
> data or object-types per network FS. Indices in the tree are used by
> FS-Cache to find objects faster. The tree or index structure under the main
> network FS index depends on the filesystem. Cookies are used to represent
> the indices, the pages etc..
> The tree structure would be as following:
> a) The virtual index tree maintained by fs-cache would look like:
> * FS-Cache master index -> The network-filesystem indice (NFS/AFS etc..)
> -> per-share indices -> File-handle indices -> Page indices
> b) In case of FUSE-based filesystems, the tree would be similar to :
> * FS-Cache master index -> FUSE indice -> Per FS indices -> file-handle
> indices -> page indices.
> c) In case of FUSE based filesystems as GlusterFS, the tree would as :
> * FS-Cache master index -> FUSE indice (fuse.glusterfs) -> GlusterFS
> volume ID (a UUID exists for each volume) - > GlusterFS file-handle indices
> (based on the GFID of a file) -> page indices.
> The idea is to enable FUSE to work with the FS-Cache network filesystem
> API, which is documented at '
> The implementation of FS-Cache support in NFS can be taken as a guideline
> to understand and start off.
> I will reply to this mail with any other updates that would come up whilst
> pursuing this further. I request any sort of feedback/suggestions, ideas,
> any pitfalls etc.. that can help in taking this further.
> Thank you,
> * http://people.redhat.com/dhowells/fscache/FS-Cache.pdf
> * http://people.redhat.com/steved/fscache/docs/HOWTO.txt
> * https://en.wikipedia.org/wiki/CacheFS
> * https://lwn.net/Articles/160122/
> * http://www.linux-mag.com/id/7378/
> Gluster-devel mailing list
> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel