On Thu, Feb 24, 2022 at 04:55:42PM -0600, Steve French wrote: > > With this proposal, you are trying to move away from cifs specific ioctl? > > Yes - since there are some applications that already use inotify > (although presumably less common than the similar API on Macs and > Windows), just fixing inotify to call into the fs to register events > is a good first step. See inotify(7) - Linux manual page e.g. Ok. Fixing one first makes it little simpler. But ultimately we probably would like to get to fixing boty inotify and fanotify. > > For the case of SMB3.1.1 the wire protocol should be fine for this > (although perhaps could be a few flags added to inotify to better > match what servers support) See > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/598f395a-e7a2-4cc8-afb3-ccb30dd2df7c > I see that "completion_filter" allows one to specify what kind of event client is interested in. Some of the events can probably mapped to existing inotify/fanotify events but others don't seem to have 1:1 mapping. For example, FILE_NOTIFY_CHANGE_SECURITY or FILE_NOTIFY_CHANGE_EA. I guess this will be a generic problem. Remote filesystem protocol might support a set of notifications which don't have any 1:1 mapping with what inotify/fanotiy support. For the case of virtiofs we are initially thinking of running linux host and server can use inoitfy/fanotify on host and then lot of events can have 1:1 mapping. But if we were to run virtiofsd on some other platform macOS or windows, then set of events supported might be very different. So mapping events will be a challege there as well. I guess client will have to keep a list of events it can support and if application tries to monitor for an event which remote fs can't support, just deny putting that watch. For example, I did not see in SMB, what's the equivalent of IN_CLOSE_WRITE or IN_OPEN. This will be a challege for applications though because while a set of event works on one filesystem it will not work on other fs and life will be hard for application writers. What about local events. I am assuming you want to supress local events and only deliver remote events. Because having both local and remote events delivered at the same time will be just confusing at best. Thanks Vivek > But there may be other APIs other than inotify that could be mapped to > what is already supported on the wire (with minor changes to the vfs) > > On Thu, Feb 24, 2022 at 3:52 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > > On Wed, Feb 23, 2022 at 11:16:33PM -0600, Steve French wrote: > > > Currently only local events can be waited on with the current notify > > > kernel API since the requests to wait on these events is not passed to > > > the filesystem. Especially for network and cluster filesystems it is > > > important that they be told that applications want to be notified of > > > these file or directory change events. > > > > > > A few years ago, discussions began on the changes needed to enable > > > support for this. Would be timely to finish those discussions, as > > > waiting on file and directory change events to network mounts is very > > > common for other OS, and would be valuable for Linux to fix. > > > > > > > This sounds like which might have some overlap with what we are trying > > to do. > > > > Currently inotify/fanotify only work for local filesystems. We were > > thinking is it possible to extend it for remote filesystems as well. My > > interest primarily was to make notifications work on virtiofs. So I > > asked Ioannis (an intern with us) to try to prototype it and see what are > > the challenges and roadblocks. > > > > He posted one version of patches just as proof of concept and only tried > > to make remote inotify work. One primary feedback from Amir was that > > this is too specific to inotify and if you are extending fsnotify, then > > it should have some support for fanotify as well. There is bunch of > > other feedback too. So Ioannis is trying to rework his patches now. > > > > https://lore.kernel.org/linux-fsdevel/20211025204634.2517-1-iangelak@xxxxxxxxxx/ > > > > Anyway, you had pointed to following commit. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs/ioctl.c?id=d26c2ddd33569667e3eeb577c4c1d966ca9192e2 > > > > So looks like application calls this cifs specific ioctl and blocks and > > unblocks when notifications comes, IIUC. > > > > I don't know about SMB and what kind of other notifications does it > > support. With this proposal, you are trying to move away from cifs > > specific ioctl? What will user use to either block or poll for the > > said notification. > > > > Sorry, I might be just completely off the mark. Just trying to find out > > if there is any overlap in what you are looking for and what we are > > trying to do. > > > > Thanks > > Vivek > > > > > -- > > > Thanks, > > > > > > Steve > > > > > > > > -- > Thanks, > > Steve >
