Re: [fuse-devel] fuse and the page cache

[Goswin v. B. <gos...@we...>]

Roman V Shaposhnik <rv...@su...> writes:

> On Fri, 2009-04-03 at 23:56 +0200, Goswin von Brederlow wrote:
>> Aditya Rajgarhia <adi...@gm...> writes:
>> 
>> > Hi Roman,
>> >
>> > Thanks for the reply. The case you have described is indeed what I was
>> > talking about. I was wondering why inode#1 returned by iget_locked() is
>> > different from inode#2 despite the same disk inode being fetched, but
>> > having looked at the code again I suppose it is because the superblock
>> > pointer passed to iget_locked() is different for native FS and fuse.
>> >
>> > -Aditya
>> 
>> Because it is not the same inode. One is an inode on the native
>> filesystem and one is an inode of the fuse filesystem. That they
>> actualy share the same data in their pages is purely accidental, a
>> quirk of your fuse filesystem implementation. The kernel has no way of
>> knowing that the two pages will have the same data.
>
> Exactly! And I feel pretty strongly that there's not much optimization
> possible here. IOW -- the separation between what the fuse application
> does and the fuse itself is part of the appeal of FUSE to begin with.
>
> Unless, of course, somebody has some magical ideas...
>
> Thanks,
> Roman.

Open the file on the native filesystem with O_SYNC so it doesn't use
the cache. That is the only thing I can think of.

Anything else would require a massive change in fuse. One I would like
to see though. Fuse would need a mode where the userspace part only
translates the read/write calls into read/write calls of other FDs
without touching any of the data itself. So instead of replying with a
buffer of data on read it would reply with fd and offset where the
kernel should fetch the data itself. The kernel could then share the
page. Call it zero-copy. :) But that would be a completly new
interface.

MfG
        Goswin