Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp340440pxm; Fri, 25 Feb 2022 09:00:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJwGn0XFXXX7iC/fL3eeMlHO4DIauE1KxFZ2NNfByo98wg83YpRG71sWVVBHlrhLkG9IkZsc X-Received: by 2002:a05:6a00:2296:b0:4e1:3029:ee2 with SMTP id f22-20020a056a00229600b004e130290ee2mr8278494pfe.22.1645808432152; Fri, 25 Feb 2022 09:00:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645808432; cv=none; d=google.com; s=arc-20160816; b=EH0WGrz9MKuot0VAavHlO8WhOqv+xvBObeVF1CVBEoQy59OgKiF4apwmd894P07wux ykTt/0urBH4xAh2BWORbP4sEDLNSJJ16AJaLIHzDRno5NALHsxH65FFxrZOTH6kxexmv D1d9nzzkXJgCH4VD0lTkKhuEKSC4NDynb3KOzKA2yCQiU6s49v4aai2UjXkmlodR2XaF aFUwsxoC7TMduARP4ImcaeJAkVdkAKs1nhCzCnUi5ZQXlKbwvb0HP9qxd2v+v1WZuOBS 7CVLLvh8kI2koFBKlkrKHl/VpHZRqmG6+ZfdcJhhU10sITgZGdy6XXJ/pYZZg4W++RNW rxsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=fqYY7w88iLzBzKsxm+iVgsvPAyDnq+ffNP0ORFfBhSI=; b=RKrbO3NmdSx/0j5AMo7t6X6OSrjK+0pNdHz/p84HDIztIwtz+bacpNsh+ksKBY36P/ cr6Sk0dWv8m7N/7x4DMqNMvQLQIZOXHxYbvgrPoNu6U75LFR4FJS+G5iv7ZisYvOY3pF EKtSwdwzZl5WO6koSZjuqmYYi73iVEdlCnpy8k2+T7T2UVPHxBekGJBdPe/QPVah6y3V nLVwco9Lon7Xp8xsFY6wPkPgRfqM8pqUd806X72soTeLngEL0PZA58RB7cuMyGk5Xjq0 I968WpuugjbjhNXNHarOpfiVkg9qO8D73M1ANB3JWoQ0cTetx6z/CbAskDLqsAG4rHoa JtfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I7qqpsCJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r13-20020a63ec4d000000b00375705f6f07si2290953pgj.466.2022.02.25.09.00.16; Fri, 25 Feb 2022 09:00:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I7qqpsCJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243070AbiBYQg3 (ORCPT + 99 others); Fri, 25 Feb 2022 11:36:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243069AbiBYQg0 (ORCPT ); Fri, 25 Feb 2022 11:36:26 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DCF0220429B for ; Fri, 25 Feb 2022 08:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645806954; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fqYY7w88iLzBzKsxm+iVgsvPAyDnq+ffNP0ORFfBhSI=; b=I7qqpsCJXIWLWDoN5f3tnXIYgZcgQxCnZ5+TjpVUuguJ4RfzrN/ce9GwTgKjy9AzmnVDpk 56DUdSI51yQUMIXlkY79Ekj71WcFx+87Xjyf96cNJ0pejitbIeALJq1aOw/UpqjFN5XDhu dv2vlX1L6+OuYOjMPu27EB3AaLaQHJ8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-648--e9CF4UpMz-0XyEgup1qLg-1; Fri, 25 Feb 2022 11:35:50 -0500 X-MC-Unique: -e9CF4UpMz-0XyEgup1qLg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3967F51A8; Fri, 25 Feb 2022 16:35:49 +0000 (UTC) Received: from horse.redhat.com (unknown [10.22.17.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id D730A7C04A; Fri, 25 Feb 2022 16:35:48 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 446602237E9; Fri, 25 Feb 2022 11:35:48 -0500 (EST) Date: Fri, 25 Feb 2022 11:35:48 -0500 From: Vivek Goyal To: Steve French Cc: Matthew Wilcox , lsf-pc@lists.linux-foundation.org, linux-fsdevel , LKML , Ioannis Angelakopoulos , CIFS , samba-technical Subject: Re: [LSF/MM/BPF TOPIC] Enabling change notification for network and cluster fs Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 25, 2022 at 09:27:55AM -0600, Steve French wrote: > On Fri, Feb 25, 2022 at 7:49 AM 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. > > 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