Re: Question about inotify calls.

[Stef Bon <stefbon at gmail dot com>]

Ah!

I do not have a patch yet. I thought it's better to share the idea
first, and then go futher from there.

I understand that the solution has to be smart and fast.

I do not know yet how to determine the filesystem and get the
abilities from there.

I haven't written code for glibc before, but can write c, do write pam
modules and fuse filesystems. If you can give me some point where I
can start, that would be nice.

I've already found:

http://www.win.tue.nl/~aeb/linux/lk/lk-8.html



which gives a good overview of the way the linux VFS is build.

Stef




2011/8/16 Carlos O'Donell <carlos@systemhalted.org>:
> On 8/15/2011 12:24 PM, Stef Bon wrote:
>> Hi,
>>
>> I'm working on several FUSE filesystems, and looking for how to make
>> inotify work on FUSE filesystems, and network
>> fs's like cifs and nfs.
>>
>> I've tried a lot till I found out a wrapper for the inotify calls are
>> the way to do it.
>>
>> To explain:
>>
>> inotify (and successors like fanotify) are onlt working for local
>> filesystems where the VFS is the only "user". This is the case
>> with a harddrive, and not with a FUSE filesystem or networkfilesystem.
>> I've been thinking that making inotify work for these
>> "outside of VFS filesystems" lies in the kernel. But then I came to
>> the idea that a wrapper does the job.
>>
>> If the wrapper detects the target fs support native inotify, the
>> normal syscall is done, like inotify_init, inotify_add_watch, rm-watch
>> etc.
>>
>> If the target fs is FUSE or a networkfs, it has to connect to that fs
>> via a socket in userspace.
>>
>> Is this possible, I'm want to know what you think.
>
> It is certainly possible.
>
> However, you must *not* slow down the fast path.
>
> Whatever you do, the implementation must be clever enough to avoid
> slowing down those syscalls for the common case.
>
> Do you have a patch you can share?
>
> Cheers,
> Carlos.
>
>