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@xxxxxxxxxxx/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.
