Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1884480yba; Tue, 2 Apr 2019 18:45:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqwQtsP5jbm2UaZld8ed22Qtvdmd2i5H2Gt/J/ZoKqHalhz7/dM14tVpn/u6MhfuI/r33w3Z X-Received: by 2002:a62:e50a:: with SMTP id n10mr49358502pff.55.1554255916741; Tue, 02 Apr 2019 18:45:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554255916; cv=none; d=google.com; s=arc-20160816; b=hrEiKFvfWLwkNOt47Zy+S+LDdiXj9AQdVfEWCFXgDN+771bg0a5vNmv+xJugZE3xNQ B7WLPGTcHda+J3dHsdV0nGfaHbDtsEGld415lL5x+75/x2qycz0hNSaXjY4YbTed0vYt TSEKw9/o7LcrtTT4gp7kOukGrUi3oFGIFuXIlTH0uFHP2UHSQgS+f81w2Md+NsGTV4kr aw8OcmWi3oAwH9Mhu/kWTJENwig87fux6VwskBodYcjqf1nc07gpvCchGE/VbDPj34PV +JtPncmgmpMVYJ+ALgeT4qiaB8+O4e9Jqtzbgb3vvNN4GO/5nY6xQuO7gCevSeALc3VN iw0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jrc7YImNm+8jcy9WS9wa4SbXinKxVChxKU+R7CdsYnQ=; b=bX+3vVeP5tfV0RF3cH0rEZsGaIYo6p02iAnbY4n5sHw3IsoqLfStJrPqv8qtl8xs77 M0XLDexL/621uPMZJIeQmczIQDmr5ASr4X8jrnXcxnGv/vREmlsmuUXv4TYdLvmUbGrE vlE5AxT8NhDKGhYcG3MAm4GjhZED0rtHti+u3qKbEhdYUCovS7ICWi3OG/XgID+y8axc pYN1S5TbyfXmqCARZqJ+1r+HHXja/j76T6uhzfZpY+UC4q7hmplmaQw27Xy92hJRmPJa uWt3ph2Np2LvnV3PiZIItV7iZk/qFe4xNGzY6ba/jn9XcPe6LhAFsXrluX0P5gu67uT6 nQHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si12385121pgj.329.2019.04.02.18.45.00; Tue, 02 Apr 2019 18:45:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726625AbfDCBoZ (ORCPT + 99 others); Tue, 2 Apr 2019 21:44:25 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:51342 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726071AbfDCBoZ (ORCPT ); Tue, 2 Apr 2019 21:44:25 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1hBUwo-0001QM-Fn; Wed, 03 Apr 2019 01:44:14 +0000 Date: Wed, 3 Apr 2019 02:44:14 +0100 From: Al Viro To: NeilBrown Cc: Jonathan Corbet , "Tobin C. Harding" , Mauro Carvalho Chehab , Randy Dunlap , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 00/24] Convert vfs.txt to vfs.rst Message-ID: <20190403014414.GN2217@ZenIV.linux.org.uk> References: <20190327051717.23225-1-tobin@kernel.org> <20190402094934.5b242dc0@lwn.net> <20190402164824.GK2217@ZenIV.linux.org.uk> <87d0m32989.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d0m32989.fsf@notabene.neil.brown.name> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 03, 2019 at 12:00:54PM +1100, NeilBrown wrote: > I would find it useful if the documentation said something about why > this API exists at all. As you say, it cannot change the dentry - so > what is it expected to do. *shrug* It tell filesystem that this dentry is going away now. > I had a look at the two in-tree users and my guess is that it can be > useful if the filesystem caches some other information which would be > invalidated by a dentry being removed. > I *think* cephfs has a flag which records if "All entries in a directory > are currently in the dcache". When a dentry is pruned, that flag needs > to be cleared. > > i.e. ->d_prune allows a filesystem to maintain summary state about what > is currently in the dcache. For one thing... Or, if you keep a (non-counting) reference to that dentry, this tells you to forget it, etc. I can think of other uses; it's really just telling the fs that this is becoming an ex-parrot.