Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <76ea04b4-bad7-8cb3-d2c6-4ad49def4e05@fujitsu.com>
Date:   Wed, 14 Sep 2022 17:38:02 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] xfs: fail dax mount if reflink is enabled on a partition
From:   =?UTF-8?B?WWFuZywgWGlhby/mnagg5pmT?= <yangx.jy@fujitsu.com>
To:     Brian Foster <bfoster@redhat.com>,
        =?UTF-8?B?UnVhbiwgU2hpeWFuZy/pmK4g5LiW6Ziz?= 
        <ruansy.fnst@fujitsu.com>
CC:     "Darrick J. Wong" <djwong@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
        "nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "david@fromorbit.com" <david@fromorbit.com>,
        "hch@infradead.org" <hch@infradead.org>
References: <20220609143435.393724-1-ruansy.fnst@fujitsu.com>
 <Yr5AV5HaleJXMmUm@magnolia>
 <74b0a034-8c77-5136-3fbd-4affb841edcb@fujitsu.com>
 <Ytl7yJJL1fdC006S@magnolia>
 <7fde89dc-2e8f-967b-d342-eb334e80255c@fujitsu.com>
 <YuNn9NkUFofmrXRG@magnolia>
 <0ea1cbe1-79d7-c22b-58bf-5860a961b680@fujitsu.com>
 <YusYDMXLYxzqMENY@magnolia>
 <dd363bd8-2dbd-5d9c-0406-380b60c5f510@fujitsu.com> <Yxs5Jb7Yt2c6R6eW@bfoster>
 <7fdc9e88-f255-6edb-7964-a5a82e9b1292@fujitsu.com>
In-Reply-To: <7fdc9e88-f255-6edb-7964-a5a82e9b1292@fujitsu.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2022/9/14 14:44, Yang, Xiao/杨 晓 wrote:
> On 2022/9/9 21:01, Brian Foster wrote:
>> Yes.. I don't recall all the internals of the tools and test, but IIRC
>> it relied on discard to perform zeroing between checkpoints or some such
>> and avoid spurious failures. The purpose of running on dm-thin was
>> merely to provide reliable discard zeroing behavior on the target device
>> and thus to allow the test to run reliably.
> Hi Brian,
> 
> As far as I know, generic/470 was original designed to verify
> mmap(MAP_SYNC) on the dm-log-writes device enabling DAX. Due to the
> reason, we need to ensure that all underlying devices under
> dm-log-writes device support DAX. However dm-thin device never supports
> DAX so
> running generic/470 with dm-thin device always returns "not run".
> 
> Please see the difference between old and new logic:
> 
>            old logic                          new logic
> ---------------------------------------------------------------
> log-writes device(DAX)                 log-writes device(DAX)
>              |                                       |
> PMEM0(DAX) + PMEM1(DAX)       Thin device(non-DAX) + PMEM1(DAX)
>                                            |
>                                          PMEM0(DAX)
> ---------------------------------------------------------------
> 
> We think dm-thin device is not a good solution for generic/470, is there
> any other solution to support both discard zero and DAX?

Hi Brian,

I have sent a patch[1] to revert your fix because I think it's not good 
for generic/470 to use thin volume as my revert patch[1] describes:
[1] 
https://lore.kernel.org/fstests/20220914090625.32207-1-yangx.jy@fujitsu.com/T/#u

With the revert, generic/470 can always run successfully on my 
environment so I wonder how to reproduce the out-of-order replay issue 
on XFS v5 filesystem?

PS: I want to reproduce the issue and try to find a better solution to 
fix it.

Best Regards,
Xiao Yang

> 
> BTW, only log-writes, stripe and linear support DAX for now.