[Gluster-devel] [fuse-devel] Feature proposal - FS-Cache support in FUSE
miklos at szeredi.hu
Wed Sep 10 14:20:30 UTC 2014
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.
More information about the Gluster-devel