Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 6Ut0L7yFzfrB6TRQQ5x4/0IbWFB4BtN6O3EFQjNrdYJ8FMKv8+rFCoA3QIUrfyVyO8gw2I7+gB
 DI+XOCQDS56A==
IronPort-SDR: /eKAMA4Z+MGLgmc7pg47zfyleZZfStf928BZ4SShuUGk9rZzdCpDBrU1XUAGBDYUIyMNfIvWzv
 f+akZuFVWrlQ==
Date:   Tue, 21 Apr 2020 20:46:09 -0700
From:   Ira Weiny <ira.weiny@intel.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     "Darrick J. Wong" <darrick.wong@oracle.com>,
        linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
        Jan Kara <jack@suse.cz>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Chinner <david@fromorbit.com>,
        Christoph Hellwig <hch@lst.de>,
        "Theodore Y. Ts'o" <tytso@mit.edu>, Jeff Moyer <jmoyer@redhat.com>,
        linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH V9 09/11] fs: Introduce DCACHE_DONTCACHE
Message-ID: <20200422034609.GH3372712@iweiny-DESK2.sc.intel.com>
References: <20200421191754.3372370-1-ira.weiny@intel.com>
 <20200421191754.3372370-10-ira.weiny@intel.com>
 <20200421202519.GC6742@magnolia>
 <20200422023407.GH23230@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200422023407.GH23230@ZenIV.linux.org.uk>
User-Agent: Mutt/1.11.1 (2018-12-01)
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 22, 2020 at 03:34:07AM +0100, Al Viro wrote:
> On Tue, Apr 21, 2020 at 01:25:19PM -0700, Darrick J. Wong wrote:
> 
> > > DCACHE_DONTCACHE indicates a dentry should not be cached on final
> > > dput().
> > > 
> > > Also add a helper function to mark DCACHE_DONTCACHE on all dentries
> > > pointing to a specific inode when that inode is being set I_DONTCACHE.
> > > 
> > > This facilitates dropping dentry references to inodes sooner which
> > > require eviction to swap S_DAX mode.
> 
> Explain, please.  Questions:
> 
> 1) does that ever happen to directories?

Directories never get S_DAX set.  So the eviction only needs to happen on
inodes.  But that can't happen without dentries also dropping their references.

> 2) how much trouble do we get if such inode is *NOT* evicted for, say, several
> days?

No trouble at all.  Users understand that changing the FS_XFLAG_DAX setting
does _not_ immediately result in S_DAX changing.

It is intended that applications requiring a change of mode would flip the
FS_XFLAG_DAX close the file and wait for the eviction (or force it through a
drop cache if they have permission).

Ira