On Thu, Dec 28, 2023 at 10:52 AM Stef Bon <stefbon@xxxxxxxxx> wrote: > > Op do 28 dec 2023 om 15:46 schreef Amir Goldstein <amir73il@xxxxxxxxx>: > > > > On Wed, Dec 27, 2023 at 7:56 PM Stef Bon <stefbon@xxxxxxxxx> wrote: > > > > > > Op wo 27 dec 2023 om 15:00 schreef Amir Goldstein <amir73il@xxxxxxxxx>: > > > > > > > > > > > > > > > > backend may not wait for the sending (and possibly receiving the > > > > > status reply) cause this may take too much time. > > > > > > > > Not sure why you think that it cannot wait. > > > > I think that setting the remote mark should wait. > > > > > > > > > > Well the send and recv can block due to various circumstances (network > > > problems, bad written software, we want to support FUSE fs's right?). > > > The system call to inotify might block cause of this and this is not > > > what you want. > > > > > > > I disagree. > > A typical workflow is: > > 1. setup watch > > 2. wait for events > > Yes i know. You do not have to explain me the workflow. I don't think > that the setting of a watch has to wait for the remote server has > received the watch, set it, and send a reply. We're talking about a > system call here (inotify_add_watch), and you don't mind it might > block? Strange. > > > > > This work of Ioannis Angelakopoulos is not implemented? What happened? > > > > > > > He posted patches. > > We provided feedback and raised some questions about the API. > > Nobody followed up on that feedback with new patches > > and not all open API questions have been resolved. > > > > > > > There is no mandate for you to implement ->fsnotify_upadate() > > in cifs, if you are only interested in FUSE. > > There is lot of miscommunication between you and me. I never said I > stick to FUSE and forget the rest. I said I start with implementing it > with FUSE, cause I'm very familiar with that. It was my response to > you saying I should start working on cifs. which I think is not for > you to decide where to start. > > > > > The mandate is to guarantee that the API you design for FUSE > > *could* work also for cifs. > > Since cifs really does implement remote notification, it would be > > very recommended to show at least a POC of how the API can > > work with cifs - I am sure that if you provide POC code, Steve > > and cifs developers would be able to test it and provide feedback. Yes - added Paulo and linux-cifs to cc > See above. My intention is to start with FUSE and if that works, make > it work for others as well. Not only cifs by the way, there are more > fs's. We should be able to get multiple people interested in fixing the inotify/fsnotify for cifs.ko mounts - it is a reasonably commonly requested function > > > Why do you think that? > > > > > > > Please follow the discussion on Ioannis patches regarding > > local vs. remote notifications - it is a mess. > > There was no consensus how local and remote notifications > > could be reported together on the same group. > > > > I will read that. For me there is no reason to keep them apart, but > some rules have to be taken care of. > > > > > I think you may have a misconception of the relationship between > > fsnotify/inotify/fanotify. > > Again, this is not the case. I know how it is designed, But inotify > and fanotify differ very much, maybe they should be designed as two > separate subsystems: > - fanotify local only, focus on open/write/close access and deny. > Provide an fd. Manage access. > - inotify only about reporting events (any!), local and remote, only a > name and a reference to a watch. -- Thanks, Steve
