<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 16, 2021 at 12:10 AM Stef Bon <<a href="mailto:stefbon@gmail.com" target="_blank">stefbon@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ioannis,<br>
<br>
I see that you have been working on making fsnotify work on virtiofs.<br>
Earlier you contacted me since I've written this:<br>
<br>
<a href="https://github.com/libfuse/libfuse/wiki/Fsnotify-and-FUSE" rel="noreferrer" target="_blank">https://github.com/libfuse/libfuse/wiki/Fsnotify-and-FUSE</a><br>
<br>
and send you my patches on 23 june.<br>
I want to mention first that I would have appreciated it if you would<br>
have reacted to me after I've sent you my patches. I did not get any<br>
reaction from you. Maybe these patches (which differ from what you<br>
propose now, but there is also a lot in common) have been an<br>
inspiration for you.<br>
<br>
Second, what I've written about is that with network filesystems (eg a<br>
backend shared with other systems) fsnotify support in FUSE has some<br>
drawbacks.<br>
In a network environment, where a network fs is part of making people<br>
collaborate, it's very useful to have information on who did what on<br>
which host, and also when. Simply a message "a file has been created<br>
in the folder you watch" is not enough. For example, if you are part<br>
of a team, and assigned to your team is a directory on a server where<br>
you can work on some shared documents. Now in this example there is a<br>
planning, and some documents have to be written. In that case you want<br>
to be informed that someone in your team has started a document (by<br>
creating it) by the system.<br>
<br></blockquote><div>I agree that the out of band approach you propose is actually more powerful, since it can</div><div>provide the client with more information than remote fsnotify. However, in the virtiofs setup </div><div>your approach might not be as efficient.</div><div><br></div><div>Specifically, the information on who did what might not make sense to the guest within QEMU, since all the</div><div>virtiofs filesystem operations are handled by viritofsd on the host and the guest does not know about the</div><div>server or any other guests. Vivek, correct me here if I am wrong.</div><div><br></div><div>Thus, for now at least, it might be sufficient for the guest to know that just a remote event</div><div>occurred. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This "extended" information will never get through fsnotify.<br>
<br>
Other info useful to you as team member:<br>
<br>
- you have become member of another team: <a href="mailto:sbon@anotherteam.example.org" target="_blank">sbon@anotherteam.example.org</a><br>
- diskspace and/or quota shortage reported by networksystem<br>
- new teammember, teammember left<br>
- your "rights" or role in the network/team have been changed (for<br>
example from reader to reader and writer to some documents)<br>
<br>
What I want to say is that in a network where lots of people work<br>
together in teams/projects, (and I want Linux to play a role there, as<br>
desktop/workstation) communication is very important, and all these<br>
messages should be supported by the system. My idea is the support of<br>
watching fs events with FUSE filesystems should go through userspace,<br>
and not via the kernel (cause fs events are part of your setup in the<br>
network, together with all other tools to make people collaborate like<br>
chat/call/text, and because mentioned above extended info about the<br>
who on what host etc is not supported by fsnotify).<br>
There should be a fs event watcher which takes care of all watches on<br>
behalf of applications during a session, similar to gamin and FAM once<br>
did (not used anymore?).<br>
When receiving a request from one of the applications this fsevent<br>
watcher will use inotify and/or fanotify for local fs's only. With a<br>
FUSE fs, it should contact (via a socket) this fs that a watch has<br>
been set on an inode with a certain mask.<br>
If the FUSE fs does not support this, fallback on normal inotify/fanotify.<br>
This way extended info is possible.<br>
<br>
Is this extended information also useful for virtiofs?<br>
<br></blockquote><div>Also based on your explanation, your out of band approach is specific to FUSE filesystems.</div><div>Granted, with your approach there is less complexity in the kernel and more flexibility since </div><div>the event notification occurs solely in user-space.</div><div>However, during the discussion with Amir and Jan about potential routes we could take to support the remote </div><div>fanotify/inotify/fsnotify one important concern was that the API should be able to support other</div><div>network/remote filesystems if needed and not only FUSE filesystems.</div><div>It seems that your approach would require a lot of work (correct me if I am wrong) to be adopted</div><div>by other network filesystems.</div><div><br></div><div>Finally, user-space applications should also be aware of your new API, which will probably result in a non-negligible effort by app developers to adopt it or change their existing apps. The remote inotify/fsnotify ( the current implementation) even though it has many limitations, relies on the existing API and should require less modifications in user space apps. That is why we chose the remote inotify/fsnotify route.</div><div><br></div><div>That said, I do not see a reason why both implementations cannot co-exist and have the user-space applications choose which approach they want. </div><div> </div><div>Thanks,</div><div>Ioannis</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Stef Bon<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Ioannis Angelakopoulos<div>Software Engineer Intern at Red Hat</div></div></div></div>