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

[Miklos Szeredi]

On Thu, Sep 4, 2014 at 5:42 PM, Goswin von Brederlow <goswin-v-b at web.de> 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 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.

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