I've been tossing this idea around inside my head for a while and I
thought I'd get some more opinions before I try hacking it out. I should
point out that I have never written any VFS code and my understanding of
how it all fits together is a little sketchy.
Every file in my filesystem is backed directly without transformation by
a file in another file system. I've noticed from the various threads in
the mailing list that others also have some or all of their files
structured in this way.
Currently all operations on such files follow the following call path:
client application -> VFS -> fuse kernel -> fuse userspace -> custom FS
-> VFS -> other FS
I would like to shortcut some of the IO calls so that they follow the path:
client application -> VFS -> fuse kernel -> other FS
I believe that doing this could yield a fairly large performance gain
for a small cost in both code lines and structural cleanliness.
The calls I'm particularly interested in are the file calls llseek,
read, write, mmap, fsync and sendfile, however I suspect that we might
need a few others to make things function cleanly.
The way I imagine this working is that when a file is opened the custom
FS's open call opens the underlying file and passes the filehandle to
fuse. Fuse then propagates the filehandle and process id down to the
kernel module where they are stored in the fuse_file structure. Then
when VFS calls one of the above operations on the fuse file, instead of
calling up to the custom FS, fuse makes the same call on the actual
file. Obviously if the custom FS open call returns without passing a
file handle then everything works just the way it does now.