All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Steve French <smfrench@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ioannis Angelakopoulos <jaggel@bu.edu>,
	CIFS <linux-cifs@vger.kernel.org>,
	samba-technical <samba-technical@lists.samba.org>
Subject: Re: [LSF/MM/BPF TOPIC] Enabling change notification for network and cluster fs
Date: Fri, 25 Feb 2022 11:35:48 -0500	[thread overview]
Message-ID: <YhkFZE8wUWhycwX2@redhat.com> (raw)
In-Reply-To: <CAH2r5mt9EtTEJCKsHkvRctfhMv7LnT6XT_JEvAb7ji6-oYnTPg@mail.gmail.com>

On Fri, Feb 25, 2022 at 09:27:55AM -0600, Steve French wrote:
> On Fri, Feb 25, 2022 at 7:49 AM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Fri, Feb 25, 2022 at 08:23:20AM -0500, Vivek Goyal wrote:
> > > 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.
> >
> > This paragraph confuses me.  If I'm writing, for example, a file manager
> > and I want it to update its display automatically when another task alters
> > the contents of a directory, I don't care whether the modification was
> > done locally or remotely.
> >
> > If I understand the SMB protocol correctly, it allows the client to take
> > out a lease on a directory and not send its modifications back to the
> > server until the client chooses to (or the server breaks the lease).
> > So you wouldn't get any remote notifications because the client hasn't
> > told the server.
> 
> Directory leases would be broken by file create so the more important
> question is what happens when client 1 has a change notification on writes
> to files in a directory then client 2 opens a file in the same directory and is
> granted a file lease and starts writing to the file (which means the
> writes could get cached).   This is probably a minor point because when
> writes get flushed from client 2, client 1 (and any others with notifications
> requested) will get notified of the event (changes to files in a directory
> that they are watching).
> 
> Local applications watching a file on a network or cluster mount in Linux
> (just as is the case with Windows, Macs etc.) should be able to be notified of
> local (cached) writes to a remote file or remote writes to the file from another
> client.  I don't think the change is large, and there was an earlier version of
> a patch circulated for this

So local notifications are generated by filesystem code as needed?

IOW, in general disable all local events and let filesystems decide which
local events to generate? And locally cached write is one such example?

Thanks
Vivek


  reply	other threads:[~2022-02-25 16:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-24  5:16 [LSF/MM/BPF TOPIC] Enabling change notification for network and cluster fs Steve French
2022-02-24 21:52 ` Vivek Goyal
2022-02-24 22:55   ` Steve French
2022-02-25 13:23     ` Vivek Goyal
2022-02-25 13:49       ` Matthew Wilcox
2022-02-25 14:30         ` Vivek Goyal
2022-02-25 15:27         ` Steve French
2022-02-25 16:35           ` Vivek Goyal [this message]
     [not found]             ` <CAH2r5msPz1JZK4OWX_=+2HTzKTZE07ACxbEv3xM-1T0HTnVWMw@mail.gmail.com>
2022-02-26 10:22               ` [Lsf-pc] " Amir Goldstein
2022-02-28  5:42                 ` Ralph Boehme
2022-02-26 16:44               ` Vivek Goyal
2022-03-11 12:36 ` Vivek Goyal

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=YhkFZE8wUWhycwX2@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=jaggel@bu.edu \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=samba-technical@lists.samba.org \
    --cc=smfrench@gmail.com \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.