[Gluster-devel] Feature proposal - FS-Cache support in FUSE

Fri Sep 5 13:55:48 UTC 2014

Hi Vimal,
     I have a simple suggestion.  I think it would be great to first 
test FS-Cache with the NFS and Samba servers in GlusterFS.  I think just 
proving these technologies work  well together without any issues would 
be great start. I am not sure if this information is already available 
with GlusterFS specifically, but it still would be great to gain this 
experience.
     Once you have enough experience with FS-Cache and standard 
protocols for GlusterFS, then you can battle FUSE.

Just my $0.02. Either way it should be fun and I look forward to your 
results :-).

- Luis

On 09/03/2014 03:25 AM, Vimal A R wrote:
> David / Dan / Anand,
>
> Thank you for all the suggestions. I will make a note of the points, 
> and will get back here if I have anything to report or doubts.
>
> Thanks a lot,
>
> Vimal
>
>
> On Tuesday, 2 September 2014 8:50 PM, Anand Avati <avati at gluster.org> 
> wrote:
>
>
>
>
>
> On Mon, Sep 1, 2014 at 6:07 AM, Vimal A R <arvimal at yahoo.in 
> <mailto: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.
>
> Thanks
>
>     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
>     'https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/caching/netfs-api.txt'.
>
>     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,
>
>     Vimal
>
>     References:
>     *
>     https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/caching/fscache.txt
>     *
>     https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/caching/netfs-api.txt
>     *
>     https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/caching/object.txt
>     * 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 <mailto:Gluster-devel at gluster.org>
>     http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140905/faf70e84/attachment-0001.html>