Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp285122ybm; Thu, 28 May 2020 02:42:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzB1CVVBA9MBfnXIZoqPrlAOesFMAmNOneggI1xnsghSRl6FGz9vNa7Y9pox+L+X1NxGbVn X-Received: by 2002:a17:906:3ed3:: with SMTP id d19mr2328998ejj.404.1590658945669; Thu, 28 May 2020 02:42:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590658945; cv=none; d=google.com; s=arc-20160816; b=0oY6zMSsHYqvMG/Cn+AVLW0PuBFep8aZDQuYqtiw6PPzdF445L4LCbrjBysNTFWiOw Q/fQvVZPxR08rUn03D+zbAkIhLd4iCnfPkuK8FvcVhD9W3rO/PUl5yScvmjpbr8uHanr cT+nxJIRcT5Fzn+x3I+LK/AFPtdnQakh1wr1Phe6JYUjRAl219sTo2W77kpmhyAViYKY g3v1GaA0Wz63KMfWLNtf/PnupRxW5+A+00YEHs+W9kTyRc6l7+mdjFGhAZ6BGBubct07 c1/PpBv/2JUwrXtwxfxX8Qf+UxSVUm1Zc+Jwkbx33wg4iAtHLnDqGNhxfiYwm5iekQqR p0Mw== 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=3ibJ5VHp+8FpUbZXzvUV68pyPbWOy1MFY+CEH2P/2jk=; b=DteMwuUBCbXgiA6GXUdddKSkQsbDn/vVKOcr4dCOSt5HxUQXd+RJ3RGFnK6DrNxLt+ fir1An4KDNgpzojQi7XpfEIqe3CalJmW+boHq2NAZAV52tjN/dsPPZJF3iIf8VNfUFmp 2FETmWwBCTVwc4Lm77CQ8xGxaoDZS8DWPZg442XJy7QkMA0pPC7Bypxq8Y9XR7yC7IJU Am/4DXkN7Gjj1MIZskP0GLS28bmo5RcTEofcl34fTUjfQWk6SWpk2DEqUwTEJytwxFjO WSnEEwf5uYb4LuVyAPKUbJHzxv9Qst1NT3cC/WW2iiwF7hRZAWG4CYsBgDZaXVv4EVc1 R5/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j93si3367806edb.331.2020.05.28.02.41.52; Thu, 28 May 2020 02:42:25 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728431AbgE1Jlr (ORCPT + 99 others); Thu, 28 May 2020 05:41:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:53500 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728300AbgE1Jlr (ORCPT ); Thu, 28 May 2020 05:41:47 -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 037BFAD81; Thu, 28 May 2020 09:41:44 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id D71171E1283; Thu, 28 May 2020 11:41:44 +0200 (CEST) Date: Thu, 28 May 2020 11:41:44 +0200 From: Jan Kara To: Xiao Yang Cc: Ira Weiny , linux-ext4@vger.kernel.org, Andreas Dilger , "Theodore Y. Ts'o" , Jan Kara , Eric Biggers , Al Viro , Dan Williams , Dave Chinner , Christoph Hellwig , Jeff Moyer , "Darrick J. Wong" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V4 6/8] fs/ext4: Make DAX mount option a tri-state Message-ID: <20200528094144.GD14550@quack2.suse.cz> References: <20200521191313.261929-1-ira.weiny@intel.com> <20200521191313.261929-7-ira.weiny@intel.com> <5ECE00AE.3010802@cn.fujitsu.com> <20200527235002.GA725853@iweiny-DESK2.sc.intel.com> <5ECF7CD3.20409@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ECF7CD3.20409@cn.fujitsu.com> 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 Thu 28-05-20 16:56:51, Xiao Yang wrote: > On 2020/5/28 7:50, Ira Weiny wrote: > > On Wed, May 27, 2020 at 01:54:54PM +0800, Xiao Yang wrote: > > > On 2020/5/22 3:13, ira.weiny@intel.com wrote: > > > > From: Ira Weiny > > > > > > > > We add 'always', 'never', and 'inode' (default). '-o dax' continues to > > > > operate the same which is equivalent to 'always'. This new > > > > functionality is limited to ext4 only. > > > > > > > > Specifically we introduce a 2nd DAX mount flag EXT4_MOUNT2_DAX_NEVER and set > > > > it and EXT4_MOUNT_DAX_ALWAYS appropriately for the mode. > > > > > > > > We also force EXT4_MOUNT2_DAX_NEVER if !CONFIG_FS_DAX. > > > > > > > > Finally, EXT4_MOUNT2_DAX_INODE is used solely to detect if the user > > > > specified that option for printing. > > > Hi Ira, > > > > > > I have two questions when reviewing this patch: > > > 1) After doing mount with the same dax=inode option, ext4/xfs shows > > > differnt output(i.e. xfs doesn't print 'dax=inode'): > > > --------------------------------------------------- > > > # mount -o dax=inode /dev/pmem0 /mnt/xfstests/test/ > > > # mount | grep pmem0 > > > /dev/pmem0 on /mnt/xfstests/test type ext4 (rw,relatime,seclabel,dax=inode) > > > > > > # mount -odax=inode /dev/pmem1 /mnt/xfstests/scratch/ > > > # mount | grep pmem1 > > > /dev/pmem1 on /mnt/xfstests/scratch type xfs > > > (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) > > > ---------------------------------------------------- > > > Is this expected output? why don't unify the output? > > > > Correct. dax=inode is the default. xfs treats that default the same whether > > you specify it on the command line or not. > > > > For ext4 Jan specifically asked that if the user specified dax=inode on the > > command line that it be printed on the mount options. If you don't specify > > anything then dax=inode is in effect but ext4 will not print anything. > > > > I had the behavior the same as XFS originally but Jan wanted it this way. The > > XFS behavior is IMO better and is what the new mount infrastructure gives by > > default. > > Could we unify the output? It is strange for me to use differnt output on > ext4 and xfs. If we'd unify the output with XFS, it would be inconsistent with all the other ext4 mount options. So I disagree with that. I agree it is not ideal to have different behavior between xfs and ext4 but such is the historical behavior. If we want to change that, we need to change the handling for all the ext4 mount options. I'm open for that discussion but it is a problem unrelated to this patch set. Honza -- Jan Kara SUSE Labs, CR