tree 10b5eea76421b48b360ee93e958169aa9616ebd5
parent 4831e935f2c875df1dfd44348c2ed8616d163e0e
author Darrick J. Wong <djwong@kernel.org> 1629141036 -0700
committer Darrick J. Wong <djwong@kernel.org> 1629243566 -0700

ext4: use DAX block device zeroout for FSDAX file ZERO_RANGE operations

Our current "advice" to people using persistent memory and FSDAX who
wish to recover upon receipt of a media error (aka 'hwpoison') event
from ACPI is to punch-hole that part of the file and then pwrite it,
which will magically cause the pmem to be reinitialized and the poison
to be cleared.

Punching doesn't make any sense at all -- the (re)allocation on pwrite
does not permit the caller to specify where to find blocks, which means
that we might not get the same pmem back.  This pushes the user farther
away from the goal of reinitializing poisoned memory and leads to
complaints about unnecessary file fragmentation.

Now that we've created a dax_zeroinit_range to perform what amounts to a
low level format of pmem, hook it up to ext4.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>