Hi, yes I agree, it's an important feature. And yes it's a challenge to design this. I've started a project page at : https://code.google.com/p/notifyfs/ Your email is not complete: you write a sentence "There is" and it stops. Is it worth sending the rest of you planned writing? Stef 2012/3/6 Steve French <smfrench@xxxxxxxxx>: > Notify is great for cifs (smb/cifs clients regularly used it as far > back as OS/2, and Windows desktops use it with cifs and smb2 as a key > feature of their desktop). What is going to be fun to figure out is > how "directory oplocks" (in smb2.2) can be used to simplify this and > make it perform even better. There is > > I am looking forward to understanding more how would like to tie this in. > > On Mon, Mar 5, 2012 at 7:15 AM, Stef Bon <stefbon@xxxxxxxxx> wrote: >> Hi, >> >> I've got a clue howto do this, but it can be wromng, since I know >> howto program sockets since some months now. >> >> It's doable with a eventfd. >> >> Notifyfs can create when dealing with cifs an event fd, and pass it >> via a socket to mount.cifs. >> Mount.cifs passes this to the kernel via an option, and when it's >> finishing, closes the socket. >> >> This way the event fd is active, and can be used for forwarding notify >> events/commands (and maybe others as well...) >> >> Please I do not want to push something here, but would like to make >> notifyfs work with filesystems like FUSE, nfs and cifs, and maybe >> others as well. I think that in near future, when more and more data >> is available remote on local servers (using existing fs's like cifs >> and nfs) AND on servers on the Internet, using a FUSE fs or something >> else (maybe cifs???) notifying the user and apps of changes is a very >> nice and good thing. Then it's up to the filesystem howto forward the >> notifyfs request. >> >> Stef >> >> >> 2012/3/5 Stef Bon <stefbon@xxxxxxxxx>: >>> Hi, >>> >>> I'm working on a successor of gamin, a file system change notifier. >>> >>> Like with gamin client apps can connect to it and instruct it to watch >>> a specific path. >>> >>> It's up to the notifyfs service to decide what backend (inotify, >>> polling etc) to use. >>> >>> New in my fs is the ability to "forward" the request to set a watch to >>> a fs. I do not have >>> a working example, but what I've got looks promising. I've got a >>> simple FUSE overlay fs, and this will use, >>> whenever it receives a request to set a watch from notifyfs, it set's >>> a inotify watch on the underlying fs, and send any event back to >>> notify fs. >>> >>> To make this possible the filesystem, here thus the FUSE overlay fs, >>> has to connect to noitifyfs when it starts up, and register itself as >>> client fs, and also has to send it's own mountpoint to notifyfs. >>> >>> I looked into the code of mount.cifs, but it's not that easy to >>> connect to via a socket, because the mainloop is in the kernel, not in >>> userspace. Is this somehowe (event fd??) still possible? >>> >>> Stef >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Thanks, > > Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
