On Thu, Sep 4, 2014 at 5:42 PM, Goswin von Brederlow <goswin-v-b@xxxxxx> wrote: > On Tue, Sep 02, 2014 at 08:20:35AM -0700, Anand Avati 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. Fuse does provide a total of 128bits of file handle identification with nodeID + generation, with some of that number-space reserved for special uses, unfortunately. Would be nice to provide for arbitrary file handle lengths. Will look into that, at least for the libfuse-3.0 API. As for a persistent cache implementation for fuse: I'd also consider using a userspace solution instead of FS-Cache. Disadvantage: separate codebase. Advantages: everything else; there's really no reason to do this in kernel, at least AFAICS. Thanks, Miklos -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
