Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Fri, 25 Feb 2022 09:30:23 -0500
From:   Vivek Goyal <vgoyal@redhat.com>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Steve French <smfrench@gmail.com>,
        lsf-pc@lists.linux-foundation.org,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ioannis Angelakopoulos <jaggel@bu.edu>
Subject: Re: [LSF/MM/BPF TOPIC] Enabling change notification for network and
 cluster fs
Message-ID: <Yhjn/zmdlAFtvRR0@redhat.com>
References: <CAH2r5mt9OfU+8PoKsmv_7aszhbw-dOuDCL6BOxb_2yRwc4HHCw@mail.gmail.com>
 <Yhf+FemcQQToB5x+@redhat.com>
 <CAH2r5mt6Sh7qorfCHWnZzc6LUDd-s_NzGB=sa-UDM2-ivzpmAQ@mail.gmail.com>
 <YhjYSMIE2NBZ/dGr@redhat.com>
 <YhjeX0HvXbED65IM@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YhjeX0HvXbED65IM@casper.infradead.org>
Precedence: bulk

On Fri, Feb 25, 2022 at 01:49:19PM +0000, Matthew Wilcox 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.

So we will get remote notifications when client flushes changes to server,
IIUC. But in this case, given changes are happening on same client, local
events will make sense because we will come to know about changes much
sooner.

But if another client was watching for changes too, it will not come to
know about these events till first client flushes these changes to
server.

Anyway, it is a good point. This is a good example of where we might want
local events too. 

This raises question how applications will handle the situation, if we allow
both local and remote events, then there will be too many duplicate events.
One event for local change and another will be sent by server when server
notices the change.

May be there needs to be a way to supress remote event if we already
generated local event. But not sure how would one figure that out. If
server can somehow not send remote events to the client which triggered
the event (and send remote events to all other clients), may be that will
help.

Havid said that, it might not be easy for server to figure out which
client triggered the event and not send remote event back to that client.

May be we should allow both local and remote events. And probably event
should carry additional property which says whether event was local or
remote. And then let application deal with it?  I am not sure, just
thinking loud. 

Thanks
Vivek