Re: [PATCH RESEND 2/2] generic/470: Replace thin volume with blkdiscard -z

["Yang, Xiao/杨 晓" <yangx.jy@fujitsu.com>]

On 2022/11/1 11:48, Darrick J. Wong wrote:
> On Sun, Oct 30, 2022 at 07:30:31AM +0000, yangx.jy@fujitsu.com wrote:
>> Hi Darrick,
>>
>> Ping, is there any feedback on the patch?
>>
>> Best Regards,
>> Xiao Yang
>>
>> -----Original Message-----
>> From: Yang, Xiao/杨 晓 <yangx.jy@fujitsu.com>
>> Sent: 2022年10月24日 15:16
>> To: Darrick J. Wong <djwong@kernel.org>
>> Cc: zlang@redhat.com; fstests@vger.kernel.org; bfoster@redhat.com
>> Subject: Re: [PATCH RESEND 2/2] generic/470: Replace thin volume with blkdiscard -z
>>
>> On 2022/10/24 12:09, Darrick J. Wong wrote:
>>> On Sun, Oct 23, 2022 at 06:48:13AM +0000,yangx.jy@fujitsu.com  wrote:
>>>> generic/470 was original designed to verify mmap(MAP_SYNC) which is
>>>> only vaild to the DAX capable device(e.g. PMEM). Thin volume[1] was
>>>> introduced to fix the inconsistent filesystem issue[2] but it make
>>>> the test become not run because it doesn't support DAX. As Darrick
>>>> mentioned[3], discarding the entire mapped range of scartch device
>>>> can fix the issue as well, so I try to use blkdiscard -z instead.
>>> That might be ok for the*other*  dm-logwrites tests, but isn't the
>>> fundamental problem here (generic/470, specifically) that device
>>> mapper cannot run on top of pmem?
>>
>> Hi Darrick,
>>
>> With the change，I didn't find any failure when running generic/470 in loops.
>> --------------------------------------------------------------
>> [root@fedora35 xfstests-dev]# ./check generic/470
>> FSTYP         -- xfs (non-debug)
>> PLATFORM      -- Linux/x86_64 fedora35 6.1.0-rc1+ #37 SMP
>> PREEMPT_DYNAMIC Fri Oct 21 19:04:57 CST 2022 MKFS_OPTIONS  -- -f /dev/pmem0 MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/pmem0 /mnt/scratch
>>
>> generic/470 6s
>> Ran: generic/470
>> Passed all 1 tests
>> --------------------------------------------------------------
>> Both dm-log-writes and PMEM support DAX so it's fine to verify
>> mmap(MAP_SYNC) with the dm-log-writes device on top of PMEM.
>>
>> Did I miss something? Why do you think there is a fundamental problem here?
> 
> Nope, you're right.  fsdax works fine, at least on these simple(r)
> device mapper devices:
> 
> $ git grep -c dax drivers/md/
> drivers/md/dm-core.h:1
> drivers/md/dm-linear.c:19
> drivers/md/dm-log-writes.c:19
> drivers/md/dm-stripe.c:19
> drivers/md/dm-table.c:18
> drivers/md/dm-target.c:4
> drivers/md/dm-writecache.c:7
> drivers/md/dm.c:36
> 
> (Most notably, dm-logwrites :))
> 
> I'll go look at the test in the morning.

Hi Darrick,

Do you have time to look at it?
I hope you can give me reviewed-by if you think this patch set is OK.

Best Regards,
Xiao Yang

> 
> --D
> 
>> Best Regards,
>> Xiao Yang
>>
>>>
>>> --D
>>>