Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1761070pxb; Thu, 28 Oct 2021 09:32:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKkPuM35BdRdahBuAPfFp+Uy35xJWScgBgjIAGdgxsJyXiMYEROH/F5stUaab1Tcv0d4Pj X-Received: by 2002:a17:907:2d12:: with SMTP id gs18mr6468299ejc.353.1635438769094; Thu, 28 Oct 2021 09:32:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635438769; cv=none; d=google.com; s=arc-20160816; b=zGBYjn0Yk3JRAqHGhmkDby07wUTetLsnJs9itzPBdh/8BP6xpSq+jUT0xu7bzB6bbF s8rh957YZHw8I+fue7Eofau725wY3AT0Q1x36b0EmSZUdfLXWuQx7vV7rd2Z0aRy56/I 2shYUbAHsm7vm6x4KO7cH19oRLGh/8PToKqOvrujHK8MxFX9EzClwrn79y6vsjo+47+n yEqUc9aIPBh9Cs9LV+kBl0xH0NDWk9oABD+yWWk3bWqK3VCgAALdfv8lCMCD/GQgkGJe Vn3vv5cdMT5Dfl2UJ20eJEtkK6s0mW9/P5IpWqL0S5QDt0KXqhn/F5tttdTDRfCf8s1g 0YxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id; bh=2P2zrBWeIEOqTyndSupo6264RzJJeE3ZMdCIcjBLpi4=; b=pVuolCclXOWD85HCMcCDLk10IQRMBNnEd9h+qroFB3xBEGdsgX78apsnxBIk36/IzR 4FI1npQLK6JJGbeeQ5DWW5tCZJiVQprIiNT/hElNXgSTN7U/XE6dSW9/Ey4QxDFXPqsN U7P6rQJHUifSWEboyMQYWKuG6KLnUl7BWgBow6Fa/maidfghnqzpP9rN5TEKI2/uGQJQ FsGlvW1ZfF2FsZdyNTnZa3cRu9SWNYmaNjeHNVb+OVE1/kw3TOiSkMjfmr4bZlH49QYx 128A81Qr52pUjApqIfOI1VoJrcEoWUWp/Zd0slwgIG/Lg+K0FFMMrpqbO98INk8jgjb+ 59rg== 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 js22si6190518ejc.708.2021.10.28.09.32.16; Thu, 28 Oct 2021 09:32:49 -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 S229925AbhJ1Qbh (ORCPT + 99 others); Thu, 28 Oct 2021 12:31:37 -0400 Received: from sandeen.net ([63.231.237.45]:35518 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229594AbhJ1Qbg (ORCPT ); Thu, 28 Oct 2021 12:31:36 -0400 Received: from [10.0.0.146] (liberator.sandeen.net [10.0.0.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 02EA078D2; Thu, 28 Oct 2021 11:27:41 -0500 (CDT) Message-ID: Date: Thu, 28 Oct 2021 11:29:08 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Vivek Goyal , Dave Chinner Cc: "Darrick J. Wong" , JeffleXu , Theodore Ts'o , adilger.kernel@dilger.ca, ira.weiny@intel.com, linux-xfs@vger.kernel.org, "linux-ext4@vger.kernel.org" , linux-fsdevel@vger.kernel.org, dan.j.williams@intel.com, Christoph Hellwig , Dave Chinner References: <26ddaf6d-fea7-ed20-cafb-decd63b2652a@linux.alibaba.com> <20211026154834.GB24307@magnolia> <20211026223317.GB5111@dread.disaster.area> From: Eric Sandeen Subject: Re: [Question] ext4/xfs: Default behavior changed after per-file DAX In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 10/27/21 8:14 AM, Vivek Goyal wrote: > On Wed, Oct 27, 2021 at 09:33:17AM +1100, Dave Chinner wrote: ... > Hi Dave, > > Thanks for all the explanaiton and background. It helps me a lot in > wrapping my head around the rationale for current design. > >> It's perfectly reasonable. If the hardware doesn't support DAX, then >> we just always behave as if dax=never is set. > > I tried mounting non-DAX block device with dax=always and it failed > saying DAX can't be used with reflink. > > [ 100.371978] XFS (vdb): DAX unsupported by block device. Turning off DAX. > [ 100.374185] XFS (vdb): DAX and reflink cannot be used together! > > So looks like first check tried to fallback to dax=never as device does > not support DAX. But later reflink check thought dax is enabled and > did not fallback to dax=never. We need to think hard about this stuff and audit it to be sure. But, I think that reflink check should probably just be removed, now that DAX files and reflinked files can co-exist on a filesystem - it's just that they can't both be active on the /same file/. I think that even "dax=always" is still just "advisory" - it means, try to enable dax on every file. It may still fail in the same ways as dax=inode (default) + flag set may fail. But ... we should go through the whole mount option / feature set / device capability logic to be sure this is all consistent. Thanks for pointing it out! -Eric >> IO