Currently the inotify interface in the kernel can only be used for
local file systems (unlike the previous change notify API used years
ago, and the change notify interface in Windows and other OS which is
primarily of interest for network file systems).
I wanted to discuss the VFS changes needed to allow inotify requests
to be passed into file systems so network and cluster file systems (as
an example in the SMB3 case this simply means sending a
SMB3_CHANGE_NOTIFY request to the server, whether Samba or Cloud
(Azure) or Mac or Windows or Network Appliance - all support the API
on the server side, the problem is that the network or cluster fs
client isn't told about the request to wait on the inotify event).
Although user space tools can use file system specific ioctls to wait
on events, it is obviously preferable to allow network and cluster
file systems to wait on events using the calls which current Linux
GUIs use.
This would allow gnome file manager GUI for example to be
automatically updated when a file is added to an open directory window
from another remote client.
It would also fix the embarrassing problem noted in the inotify man page:
"Inotify reports only events that a user-space program triggers
through the filesystem
API. As a result, it does not catch remote events that occur
on network filesystems."
but that is precisely the types of notifications that are most useful
... users often are aware of updates to local directories from the
same system, but ... automatic notifications that allow GUIs to be
updated on changes from **other** clients is of more value (and this
is exactly what the equivalent API allows on other OS).
The changes to the Linux VFS are small.
--
Thanks,
Steve
