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@xxxxxxxxxxx> wrote:
On Mon, Sep 1, 2014 at 6:07 AM, Vimal A R <arvimal@xxxxxxxx> 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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
