Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2462277pxm; Fri, 25 Feb 2022 02:23:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJwF5r0CGr7uwCRUibZ+PNphXZ00f0J0jjYBrmAlfrv55i9IUS5KN6WzbxBTaMfQVUmBUafv X-Received: by 2002:a17:906:9f06:b0:6ce:36da:8247 with SMTP id fy6-20020a1709069f0600b006ce36da8247mr5516855ejc.651.1645784593255; Fri, 25 Feb 2022 02:23:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645784593; cv=none; d=google.com; s=arc-20160816; b=BF2oX6ByDEkbjKs+AzpzwgXeStLGY8owb6JBHGyTtPyCEtJqQ+5bjBgIR5u9YN+YQl xToyEedxowgQnt5B19IXmGTAUBKoWQEyLB0XSBpfTWFTE/Ojgsz5/lbjq9tKz4LB5bK/ bx7iOfAdpIALNDFSXF0N4imDDtA7pX15EP1AD15ECXGMtAkX60sWn0y1LfQeiOVeFxgS h5RY+fNtSK1O74DOkuIjrB6a1rvNgwlg2BxDGlaDg2CmFXYFaa3slzez1e4833f6n1x2 yQbqebOooz1mx82S4LWOSehph4i+svVNeLnA8BdCv2eM7efa2zNQRlfjIk1aVTNp+Fnr oMPQ== 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=7C/VNCLxi2m6BpK/5znlmSIklDnXHXKYOG0purixHNw=; b=WuL50YnPwLQpeByOe6UND1kmyLXDjehm62zz872as1VU3ZZ5D1tJNvgm07QWqcE26n e1irU5HRNWmr9KxyTBJVrGdyg0YDH87fuTu4FAbGXZblhPzdC+5w/iScy5d7zbOn3kn2 ydglw7orZ4lPFxpktkn09z6OkKfjK6tI24ymeQBrUp3d/b20jn6/SWdHgtTUXetF+Emk JLMuozjMKmyMl7BxkWIzg9MBWj78XRT3a7tpchK2A3Fg1GDQfD0M1U/H/zYVH5Y2tmxX e0hMUYJeV3gVwJPd70hEnAfRhXAGNI7QK8pLB/sIcXVwEDBmHdiGkmsFEwO963AoKPLK HT9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZeVy3toV; 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 q6-20020a170906b28600b006a785a8d528si1198395ejz.7.2022.02.25.02.22.47; Fri, 25 Feb 2022 02:23:13 -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=ZeVy3toV; 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 S234497AbiBXVxC (ORCPT + 99 others); Thu, 24 Feb 2022 16:53:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233737AbiBXVw6 (ORCPT ); Thu, 24 Feb 2022 16:52:58 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 081FA14D734 for ; Thu, 24 Feb 2022 13:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645739547; 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=7C/VNCLxi2m6BpK/5znlmSIklDnXHXKYOG0purixHNw=; b=ZeVy3toV1dQnP67ZZI5aM2Gar8jZOUT7KMX74KCXuf0wkmBYu6nj46zrzoiribSqil/H62 Cz7kvN6UaqBwMQ9R3+OydfnVvMBd5MFVHoFiWVXpPKM6kvhFsVhdxnzUUDqNICP90nshjp ho/1doo/gGDdQL8osoUk54kw0+7vM7c= 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-663-rXgXQ81VOvCJtuyblKFViQ-1; Thu, 24 Feb 2022 16:52:23 -0500 X-MC-Unique: rXgXQ81VOvCJtuyblKFViQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 035A4800482; Thu, 24 Feb 2022 21:52:22 +0000 (UTC) Received: from horse.redhat.com (unknown [10.22.9.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id D85E44CEFB; Thu, 24 Feb 2022 21:52:21 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 5FF872237E9; Thu, 24 Feb 2022 16:52:21 -0500 (EST) Date: Thu, 24 Feb 2022 16:52:21 -0500 From: Vivek Goyal To: Steve French Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel , LKML , Ioannis Angelakopoulos 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.15 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=unavailable 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 Wed, Feb 23, 2022 at 11:16:33PM -0600, Steve French wrote: > Currently only local events can be waited on with the current notify > kernel API since the requests to wait on these events is not passed to > the filesystem. Especially for network and cluster filesystems it is > important that they be told that applications want to be notified of > these file or directory change events. > > A few years ago, discussions began on the changes needed to enable > support for this. Would be timely to finish those discussions, as > waiting on file and directory change events to network mounts is very > common for other OS, and would be valuable for Linux to fix. > This sounds like which might have some overlap with what we are trying to do. Currently inotify/fanotify only work for local filesystems. We were thinking is it possible to extend it for remote filesystems as well. My interest primarily was to make notifications work on virtiofs. So I asked Ioannis (an intern with us) to try to prototype it and see what are the challenges and roadblocks. He posted one version of patches just as proof of concept and only tried to make remote inotify work. One primary feedback from Amir was that this is too specific to inotify and if you are extending fsnotify, then it should have some support for fanotify as well. There is bunch of other feedback too. So Ioannis is trying to rework his patches now. https://lore.kernel.org/linux-fsdevel/20211025204634.2517-1-iangelak@redhat.com/ Anyway, you had pointed to following commit. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs/ioctl.c?id=d26c2ddd33569667e3eeb577c4c1d966ca9192e2 So looks like application calls this cifs specific ioctl and blocks and unblocks when notifications comes, IIUC. I don't know about SMB and what kind of other notifications does it support. With this proposal, you are trying to move away from cifs specific ioctl? What will user use to either block or poll for the said notification. Sorry, I might be just completely off the mark. Just trying to find out if there is any overlap in what you are looking for and what we are trying to do. Thanks Vivek > -- > Thanks, > > Steve >