linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Cc: CIFS <linux-cifs@vger.kernel.org>,
	samba-technical <samba-technical@lists.samba.org>
Subject: [LFS/MM TOPIC] Enabling file and directory change notification for network and cluster file systems
Date: Mon, 20 Jan 2020 21:55:06 -0600	[thread overview]
Message-ID: <CAH2r5mvUmZca8TRVsyZvrB_Loeeo4Kd8T7rHw5s6iaN=yC+O_Q@mail.gmail.com> (raw)

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

             reply	other threads:[~2020-01-21  3:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21  3:55 Steve French [this message]
2020-01-21  7:47 ` [LFS/MM TOPIC] Enabling file and directory change notification for network and cluster file systems Amir Goldstein
2020-01-21  7:49   ` Amir Goldstein
2020-01-21  8:30   ` ronnie sahlberg
2020-01-21  9:43     ` Amir Goldstein
2020-01-21 10:02       ` ronnie sahlberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH2r5mvUmZca8TRVsyZvrB_Loeeo4Kd8T7rHw5s6iaN=yC+O_Q@mail.gmail.com' \
    --to=smfrench@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).