Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2421748ybh; Mon, 16 Mar 2020 02:54:08 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsfrnAxSJBbN4hPy6Rf9tG2G0vMVo8tNkMymvcVyle5dkDz4tujBz+Bwp8pyRCSTsLM8ZwY X-Received: by 2002:a9d:4d8a:: with SMTP id u10mr5650858otk.148.1584352448076; Mon, 16 Mar 2020 02:54:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584352448; cv=none; d=google.com; s=arc-20160816; b=YTV4cxo1H6283gF9eu/KlxWFJa0lm9uclZ6aks27zGGUfo0IqfV8K0oEuQ3ZER0QzU ZusbSuazUyu2VdLBVJmHLTF0m9ImaRAwZ2s5LC+9Tttl1cYMFK1VSVQgD2sdm6Z5lU1j l8sHMlRtPanYJ9N4BacffozpNM98+cLR1U6hMAXuzBEtIOt5XR0D5BAcFybRq4IjedMC Nb0x1uuYUxqB9RxIT8eevw2z2/mBmXgymZsOf5wNuruZg7jNmGPnT9yemyTXouTvK4lW 06iiKI2mUaPG/rAfEHyTf8QcKBnQ5FWh2EW8Lcitfrzjqo+mB/nkO4LfyPH6WhYdRgu7 t1fA== 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=vHxv4560lQeP4G7fp5D7HMwiYVI6nveNBjobs3nDnz0=; b=W8NYyJN4fzryJJ87sU1BjLJqz8BdQZvRdgrfeOogfCbgmvzwJPrOgNQGrkWoGLrwLC pTqIMYLpSFlIpegDLnGJUWsBbccC5u+Rwpds2An4awaB/pVCdDPOYCbdZAjtGct2oJQB 5FUxOpBZnixX7QiRo5pnGrMtTgD1enRrPrb9SrcO9cODcQxB1sCJaUsmS6vVeQ8DXpdS BEFyoOL6RS5ynbEjeFYk3jL4kiPSKmiCzpDUz+tCK5oVftsMS9HQLSYXBzSwD/VgtUyk 4hMw628sQoeeHetXl9IUyXxpdmhEfPly8sDXsfO8pWUD5jxL4dHJDQGLdmrDojxaZ02w 1hXg== 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 u9si698409otq.92.2020.03.16.02.53.51; Mon, 16 Mar 2020 02:54:08 -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 S1730478AbgCPJwa (ORCPT + 99 others); Mon, 16 Mar 2020 05:52:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:42708 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730088AbgCPJwa (ORCPT ); Mon, 16 Mar 2020 05:52:30 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8A7E7B117; Mon, 16 Mar 2020 09:52:28 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 555B51E10DA; Mon, 16 Mar 2020 10:52:24 +0100 (CET) Date: Mon, 16 Mar 2020 10:52:24 +0100 From: Jan Kara To: Dan Williams Cc: Christoph Hellwig , "Darrick J. Wong" , Ira Weiny , Linux Kernel Mailing List , Alexander Viro , Dave Chinner , "Theodore Y. Ts'o" , Jan Kara , 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: <20200316095224.GF12783@quack2.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed 11-03-20 10:07:18, Dan Williams wrote: > On Tue, Mar 10, 2020 at 11:30 PM Christoph Hellwig wrote: > > > > On Tue, Mar 10, 2020 at 08:36:14PM -0700, Darrick J. Wong wrote: > > > 1) Leave the inode flag (FS_XFLAG_DAX) as it is, and export the S_DAX > > > status via statx. Document that changes to FS_XFLAG_DAX do not take > > > effect immediately and that one must check statx to find out the real > > > mode. If we choose this, I would also deprecate the dax mount option; > > > send in my mkfs.xfs patch to make it so that you can set FS_XFLAG_DAX on > > > all files at mkfs time; and we can finally lay this whole thing to rest. > > > This is the closest to what we have today. > > > > > > 2) Withdraw FS_XFLAG_DAX entirely, and let the kernel choose based on > > > usage patterns, hardware heuristics, or spiteful arbitrariness. > > > > 3) Only allow changing FS_XFLAG_DAX on directories or files that do > > not have blocks allocated to them yet, and side step all the hard > > problems. > > This sounds reasonable to me. > > As for deprecating the mount option, I think at a minimum it needs to > continue be accepted as an option even if it is ignored to not break > existing setups. Agreed. But that's how we usually deprecate mount options. Also I'd say that statx() support for reporting DAX state and some education of programmers using DAX is required before we deprecate the mount option since currently applications check 'dax' mount option to determine how much memory they need to set aside for page cache before they consume everything else on the machine... Honza -- Jan Kara SUSE Labs, CR