Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1500079ybb; Thu, 2 Apr 2020 01:54:45 -0700 (PDT) X-Google-Smtp-Source: APiQypLs9NRGZ3/KCWyWf2uMjzX0pZ6zqQTfmtVnhrL82JCzcfYbJQqYQNDUzCjSS/4r++MExvck X-Received: by 2002:a05:6830:1e82:: with SMTP id n2mr1607138otr.338.1585817685812; Thu, 02 Apr 2020 01:54:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585817685; cv=none; d=google.com; s=arc-20160816; b=GJ+SnEVl3yWH5RnOq7iy+iNiSSa/ShaRckfvi7j2PPTQrXpLipg6xZgKLH1T9yN36w w+41Gt2WzqRmNBgUHMiijYqOs4yWtKC0wb3ei2Mv14d+WslPvSiL4WzS3z+UuPXDUrBN HNkz5kY4MZvZBSxvFnQNo+g0qrI5UtURfpHMo6Yqf8CAOapt54PCDPVlY17li494MFMl GpOlV8WjFXoT3HmE7KuExSUmOCykAdbNMs4SOsfKFN6IOPp1doTPF4VA7Ja+W4GWgv7u gZNuugofgIsANx3J7wx93YOoWxbA2HS1RrjxYYD4qYRBo2AGtIn5vp84PG50KJSfTjYR yRQA== 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=syEfdB6kwOg2puUBRFn55Y83WT3o/QjL/QyWUO+T59M=; b=w6I1ErCTT9mc2WCnyf6eZnfQbSRVCzey+Fx8JFe9eAARzQO3vbRkouIRfDAikEaQnF S7UvcRt5pzFvlwXjsm0DoyZI7CPBkKgjx1nL7QLZRpzmhCF0TnX1nS/oaRoQbq9ReRWE aLgVeVjtYcO609wqwSbun7djKbK16WxRKgYUvv+W5t6hFYujW6HAEa9phGqDgMa5NUR+ H7QId9KXPfUjTrZJyeytwJpH57beb5ZU1nDn94w50bLjrnpYVo9qVYLyqTxdJnpw9627 +19L6KqQA2UEN6eX5rDnm6m15P8y6z1Ec9zJYyYcWHjmu1IswOXcczP5AfHXjgaEL6mL AHDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 o63si2156300oih.74.2020.04.02.01.54.25; Thu, 02 Apr 2020 01:54:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387880AbgDBIxa (ORCPT + 99 others); Thu, 2 Apr 2020 04:53:30 -0400 Received: from verein.lst.de ([213.95.11.211]:47447 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387875AbgDBIxa (ORCPT ); Thu, 2 Apr 2020 04:53:30 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id EFB8368C4E; Thu, 2 Apr 2020 10:53:27 +0200 (CEST) Date: Thu, 2 Apr 2020 10:53:27 +0200 From: Christoph Hellwig To: Jan Kara Cc: "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , "Theodore Y. Ts'o" , Dan Williams , Ira Weiny , Linux Kernel Mailing List , Alexander Viro , linux-ext4 , linux-xfs , linux-fsdevel , Andrew Morton , Linus Torvalds Subject: Re: [PATCH V5 00/12] Enable per-file/per-directory DAX operations V5 Message-ID: <20200402085327.GA19109@lst.de> References: <20200227052442.22524-1-ira.weiny@intel.com> <20200305155144.GA5598@lst.de> <20200309170437.GA271052@iweiny-DESK2.sc.intel.com> <20200311033614.GQ1752567@magnolia> <20200311062952.GA11519@lst.de> <20200316095224.GF12783@quack2.suse.cz> <20200316095509.GA13788@lst.de> <20200401040021.GC56958@magnolia> <20200401102511.GC19466@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200401102511.GC19466@quack2.suse.cz> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Apr 01, 2020 at 12:25:11PM +0200, Jan Kara wrote: > > - Applications must call statx to discover the current S_DAX state. > > > > - There exists an advisory file inode flag FS_XFLAG_DAX that can be > > changed on files that have no blocks allocated to them. Changing > > this flag does not necessarily change the S_DAX state immediately > > but programs can query the S_DAX state via statx. > > I generally like the proposal but I think the fact that toggling > FS_XFLAG_DAX will not have immediate effect on S_DAX will cause quite some > confusion and ultimately bug reports. I'm thinking whether we could somehow > improve this... For example an ioctl that would try to make set inode flags > effective by evicting the inode (and returning EBUSY if the eviction is > impossible for some reason)? I'd just return an error for that case, don't play silly games like evicting the inode.