On Mon, 2011-05-02 at 16:56 +0200, Stef Bon wrote: > Sorry, > > Gamin is in the first place completly useless in my case. Futher I've > tried to contact the developer of gamin, but no response at all, from > different addresses. > > And also with other fs's like cifs (and I think nfs as well), what I > try to achieve is that the fs self is responsible for the handling of > the inotify request. > > How to do this? First possible via VFS, clients will set a watch on > (mounted) fs directly, VFS handles this call and forwards it to the > mounted fs. I write here forward, I mean sends a signal to the mounted > fs about a notify watch being set on a inode. After that (and being > successfull) the VFS opens a fd the mounted fs can send events to when > something happens on the inode (what is significant). > > Next via a daemon like Gamin. Yes, possible, but is this smart? Isn't > it just possible through the VFS like above described. All filesystems should already support notification for files that are created through the VFS. The missing bit is to support notification for files that are created on the _server_ and that never go through the client VFS. That is precisely the problem that projects such as FAM and gamin are supposed to solve using generic userland daemons that can re-export the notifications from the NFS/CIFS/... server to any interested listeners. Note that there is no NFS protocol support for notifications in v2, v3 or v4. NFSv4.1 does have some limited protocol support for notifications (dnotify only), but we haven't implemented them on Linux. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
