linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Holmberg <hans.holmberg@wdc.com>
To: linux-xfs@vger.kernel.org
Cc: Carlos Maiolino <cem@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	libc-alpha@sourceware.org, Hans Holmberg <hans.holmberg@wdc.com>
Subject: [RFC] xfs: fake fallocate success for always CoW inodes
Date: Thu,  6 Nov 2025 14:35:30 +0100	[thread overview]
Message-ID: <20251106133530.12927-1-hans.holmberg@wdc.com> (raw)

We don't support preallocations for CoW inodes and we currently fail
with -EOPNOTSUPP, but this causes an issue for users of glibc's
posix_fallocate[1]. If fallocate fails, posix_fallocate falls back on
writing actual data into the range to try to allocate blocks that way.
That does not actually gurantee anything for CoW inodes however as we
write out of place.

So, for this case, users of posix_fallocate will end up writing data
unnecessarily AND be left with a broken promise of being able to
overwrite the range without ending up with -ENOSPC.

So, to avoid the useless data copy that just increases the risk of
-ENOSPC, warn the user and fake that the allocation was successful.

User space using fallocate[2] for preallocation will now be notified of
the missing support for CoW inodes via a logged warning in stead of via
the return value. This is not great, but having posix_fallocate write
useless data and still not guarantee overwrites is arguably worse.

A mount option to choose between these two evils would be good to add,
but we would need to agree on the default value first.

[1] https://man7.org/linux/man-pages/man3/posix_fallocate.3.html
[2] https://man7.org/linux/man-pages/man2/fallocate.2.html

Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
---
 fs/xfs/xfs_bmap_util.c | 15 ++++++++++++++-
 fs/xfs/xfs_file.c      |  7 -------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 06ca11731e43..ff7f6aa41fc8 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -659,8 +659,21 @@ xfs_alloc_file_space(
 	xfs_bmbt_irec_t		imaps[1], *imapp;
 	int			error;
 
-	if (xfs_is_always_cow_inode(ip))
+	/*
+	 * If always_cow mode we can't use preallocations and thus should not
+	 * create them.
+	 */
+	if (xfs_is_always_cow_inode(ip)) {
+		/*
+		 * In stead of failing the fallocate, pretend it was successful
+		 * to avoid glibc posix_fallocate to fall back on writing actual
+		 * data that won't guarantee that the range can be overwritten
+		 * either.
+		 */
+		xfs_warn_once(mp,
+"Always CoW inodes do not support preallocations, faking fallocate success.");
 		return 0;
+	}
 
 	trace_xfs_alloc_file_space(ip);
 
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 2702fef2c90c..91e2693873c0 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1312,13 +1312,6 @@ xfs_falloc_allocate_range(
 	loff_t			new_size = 0;
 	int			error;
 
-	/*
-	 * If always_cow mode we can't use preallocations and thus should not
-	 * create them.
-	 */
-	if (xfs_is_always_cow_inode(XFS_I(inode)))
-		return -EOPNOTSUPP;
-
 	error = xfs_falloc_newsize(file, mode, offset, len, &new_size);
 	if (error)
 		return error;
-- 
2.34.1


             reply	other threads:[~2025-11-06 13:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-06 13:35 Hans Holmberg [this message]
2025-11-06 13:48 ` [RFC] xfs: fake fallocate success for always CoW inodes Florian Weimer
2025-11-06 13:52   ` Christoph Hellwig
2025-11-06 14:42     ` Matthew Wilcox
2025-11-06 14:46       ` Christoph Hellwig
2025-11-11  8:31         ` Hans Holmberg
2025-11-11  9:05           ` hch
2025-11-11  9:50             ` Florian Weimer
2025-11-11 13:40               ` hch
2025-11-06 16:31       ` Florian Weimer
2025-11-06 17:05         ` Christoph Hellwig
2025-11-08 12:30           ` Florian Weimer
2025-11-09 22:15             ` Dave Chinner
2025-11-10  5:27               ` Florian Weimer
2025-11-10  9:38                 ` Christoph Hellwig
2025-11-10 10:03                   ` Florian Weimer
2025-11-10 20:28                 ` Dave Chinner
2025-11-11  8:56                   ` Christoph Hellwig
2025-11-10  9:37               ` Christoph Hellwig
2025-11-10  9:44                 ` Florian Weimer
2025-11-10 21:33                 ` Dave Chinner
2025-11-11  9:04                   ` Christoph Hellwig
2025-11-11  9:30                   ` Florian Weimer
2025-11-10  9:31             ` Christoph Hellwig
2025-11-10  9:48               ` truncatat? was, " Christoph Hellwig
2025-11-10 10:00                 ` Florian Weimer
2025-11-10  9:49               ` Florian Weimer
2025-11-10  9:52                 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251106133530.12927-1-hans.holmberg@wdc.com \
    --to=hans.holmberg@wdc.com \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).