From 47230dcee225a1314fc4af38d4fb92a7a7eaa50d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" Date: Mon, 16 Aug 2021 12:10:36 -0700 Subject: 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 --- fs/ext4/extents.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 92ad64b89d9b..8c99e591f797 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -29,6 +29,7 @@ #include #include #include +#include #include "ext4_jbd2.h" #include "ext4_extents.h" #include "xattr.h" @@ -4678,6 +4679,26 @@ long ext4_fallocate(struct file *file, int mode, loff_t offset, loff_t len) } if (mode & FALLOC_FL_ZERO_RANGE) { + /* + * If the file is in DAX mode, try to use a DAX-specific + * function to zero the region. + */ + if (IS_DAX(inode)) { + bool did_zeroout = false; + + inode_lock(inode); + + ret = dax_zeroinit_range(inode, offset, len, + &did_zeroout, &ext4_iomap_report_ops); + if (ret == -EINVAL) + ret = 0; + if (ret || did_zeroout) { + max_blocks = 0; + goto out; + } + + inode_unlock(inode); + } ret = ext4_zero_range(file, offset, len, mode); goto exit; } -- cgit v1.2.3