Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1460310pxb; Tue, 26 Oct 2021 09:23:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMa9bXOW3POwP2TFf/lXeFbjGkfcolczcJpg/v92g/LzZM3nB8IQrj21hbAhBFCI9RN/SF X-Received: by 2002:a17:906:2c1a:: with SMTP id e26mr17085368ejh.404.1635265385444; Tue, 26 Oct 2021 09:23:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635265385; cv=none; d=google.com; s=arc-20160816; b=VNTf8CfBCku16LZqCKjPLHJrCSjn8D+GMXaWo22z3TmYAgnA/p5yVsGihMRUxIrTRW UI7Iw54JaWRGd1z+EKRboBDs19TlWR1khtvDKfowBK+iurBAFscnJC26sG+MmJJzoAQS Sskh+1zRkgIuM+MiC6itAyy4m65o+JYrRAmhQLZUujAXwgTjuIhtw5b0Iuia9KCdG2uN Y9BC33N6NFE7psHs8evSF4dJlpIj8WdpEBQuGBYeRLJjgukLrWlQhUnZcXO5PQkbIxIa X819SUITi3r2YKVRwZnvA0p41Z8xjwMBV0Xv0r3aj2e8zs1GQqyF3VVMB/rJkKOzmjxQ kVGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:subject:from:cc:to; bh=Us+lnhmjTJvqhMfndbK3Q3U1zUsTXYVSdeBYyJbjSes=; b=LZJyqXXh2uTmDMkWh0sJRqAZvdaZz/eXBOzY7UcXCQE5b8JpkiVCuqhQ+LavUiU9+x pK1XFI/W2aODPJ/TpcyG+uz8iMAOXFDTfclC1JAxoGSYPAivkI5OqhGhvgowSpJE1Rx0 F0nE8asw/0J8+AITsSFP7+SJMQ44vyr6BWi2Nz5BgkuqYIuye3ZJK/6y+br/kDyirSvF Rs8oydtDyRV5+Wtc4wkACLLFtNvIsXnAWEdIPWKlX6bri5MknCTduhhFNcyeJXNYUf6L AoKKOH/GKdXcz7/ykjm1OyMt7D4rnA8vngwdQZxiTgn93ViZjApG22EziiWp6Ihan/ca B+hg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u13si4949137edp.551.2021.10.26.09.22.39; Tue, 26 Oct 2021 09:23:05 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236432AbhJZOOo (ORCPT + 99 others); Tue, 26 Oct 2021 10:14:44 -0400 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:36654 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236431AbhJZOOo (ORCPT ); Tue, 26 Oct 2021 10:14:44 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0Utn9eYf_1635257537; Received: from admindeMacBook-Pro-2.local(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0Utn9eYf_1635257537) by smtp.aliyun-inc.com(127.0.0.1); Tue, 26 Oct 2021 22:12:18 +0800 To: Theodore Ts'o , adilger.kernel@dilger.ca, "Darrick J. Wong" , ira.weiny@intel.com Cc: linux-xfs@vger.kernel.org, "linux-ext4@vger.kernel.org" , linux-fsdevel@vger.kernel.org, dan.j.williams@intel.com, Vivek Goyal , Christoph Hellwig From: JeffleXu Subject: [Question] ext4/xfs: Default behavior changed after per-file DAX Message-ID: <26ddaf6d-fea7-ed20-cafb-decd63b2652a@linux.alibaba.com> Date: Tue, 26 Oct 2021 22:12:17 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi, Recently I'm working on supporting per-file DAX for virtiofs [1]. Vivek Goyal and I are interested [2] why the default behavior has changed since introduction of per-file DAX on ext4 and xfs [3][4]. That is, before the introduction of per-file DAX, when user doesn't specify '-o dax', DAX is disabled for all files. After supporting per-file DAX, when neither '-o dax' nor '-o dax=always|inode|never' is specified, it actually works in a '-o dax=inode' way if the underlying blkdev is DAX capable, i.e. depending on the persistent inode flag. That is, the default behavior has changed from user's perspective. We are not sure if this is intentional or not. Appreciate if anyone could offer some hint. [1] https://lore.kernel.org/all/YW2Oj4FrIB8do3zX@redhat.com/T/ [2] https://lore.kernel.org/all/YW2Oj4FrIB8do3zX@redhat.com/T/#mf067498887ca2023c64c8b8f6aec879557eb28f8 [3] 9cb20f94afcd2964944f9468e38da736ee855b19 ("fs/ext4: Make DAX mount option a tri-state") [4] 02beb2686ff964884756c581d513e103542dcc6a ("fs/xfs: Make DAX mount option a tri-state") -- Thanks, Jeffle