From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Alexey Kuznetsov <kuznet@virtuozzo.com>,
OpenVZ devel list <devel@openvz.org>
Cc: "Denis V. Lunev" <den@virtuozzo.com>
Subject: [Devel] [PATCH vz10 v3] fs/ext4: let FALLOC_FL_PREALLOCATE through the vfs_fallocate mode switch
Date: Mon, 7 Sep 2026 16:10:09 +0200 [thread overview]
Message-ID: <20260907141009.1728909-1-khorenko@virtuozzo.com> (raw)
From: Alexey Kuznetsov <kuznet@virtuozzo.com>
Upstream commit 57413d8e172c ("fs: sort out the fallocate mode vs flag
mess") replaced the FALLOC_FL_SUPPORTED_MASK check in vfs_fallocate()
with a switch over FALLOC_FL_MODE_MASK that rejects unlisted modes with
EOPNOTSUPP, and ext4_fallocate() got a dedicated ALLOCATE_RANGE path.
The vz10 port of FALLOC_FL_PREALLOCATE only added the bit to the mask,
so fallocate(FALLOC_FL_PREALLOCATE) fails with EOPNOTSUPP before it
reaches ext4, and vstorage falls back to the slow path, which halves
its write performance.
Accept the mode in vfs_fallocate() and route it to ext4_do_fallocate()
together with plain allocation; ext4_alloc_file_blocks() already
honours the flag.
The falloc_prealloc description in the commit being fixed has the two
middle cases inverted and states its sizes in bytes where the code
counts blocks. Corrected:
khorenko@: logic is the following:
if FALLOC_FL_PREALLOCATE
preallocation enabled for all "len"
if !FALLOC_FL_PREALLOCATE
if len <= falloc_prealloc
preallocation enabled
if falloc_prealloc < len <= EXT_UNWRITTEN_MAX_LEN
preallocation disabled
if len > EXT_UNWRITTEN_MAX_LEN
preallocation enabled
So if FALLOC_FL_PREALLOCATE is used, fallocate() behaves like write(),
i.e. always uses preallocation, the falloc_prealloc value is ignored.
If FALLOC_FL_PREALLOCATE is NOT used:
- stock fallocate() disables preallocation for len sizes
<= EXT_UNWRITTEN_MAX_LEN, that is 32767 blocks.
- introduced falloc_prealloc allows to make an experiment:
if we set non-zero falloc_prealloc parameter (in blocks),
preallocation will be disabled for sizes
falloc_prealloc .. EXT_UNWRITTEN_MAX_LEN.
The idea behind: if you perform a small fallocate, you probably do
not mean to fragment the file.
Fixes: 275be8b96ddf ("fs/ext4: introduce FALLOC_FL_PREALLOCATE flag to fallocate")
https://virtuozzo.atlassian.net/browse/VSTOR-142784
Signed-off-by: Alexey Kuznetsov <kuznet@virtuozzo.com>
Feature: ext4: preallocation flag for small fallocates
---
v2 -> v3: commit message enhanced
---
fs/ext4/extents.c | 3 ++-
fs/open.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index b771cb594c061..38f50770f6585 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4769,7 +4769,8 @@ long ext4_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
if (ret)
goto out_inode_lock;
- if ((mode & FALLOC_FL_MODE_MASK) == FALLOC_FL_ALLOCATE_RANGE) {
+ if ((mode & FALLOC_FL_MODE_MASK) == FALLOC_FL_ALLOCATE_RANGE ||
+ (mode & FALLOC_FL_MODE_MASK) == FALLOC_FL_PREALLOCATE) {
ret = ext4_do_fallocate(file, offset, len, mode);
goto out_inode_lock;
}
diff --git a/fs/open.c b/fs/open.c
index 91f4785b89f3c..fc72ad09e7e81 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -267,6 +267,7 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
case FALLOC_FL_ALLOCATE_RANGE:
case FALLOC_FL_UNSHARE_RANGE:
case FALLOC_FL_ZERO_RANGE:
+ case FALLOC_FL_PREALLOCATE:
break;
case FALLOC_FL_PUNCH_HOLE:
if (!(mode & FALLOC_FL_KEEP_SIZE))
--
2.43.0
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next reply other threads:[~2026-09-07 14:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 14:10 Konstantin Khorenko [this message]
2026-09-07 15:29 ` Konstantin Khorenko
2026-09-07 16:26 ` Alexey Kuznetsov
2026-09-08 8:26 ` Konstantin Khorenko
2026-09-08 8:28 ` Konstantin Khorenko
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=20260907141009.1728909-1-khorenko@virtuozzo.com \
--to=khorenko@virtuozzo.com \
--cc=den@virtuozzo.com \
--cc=devel@openvz.org \
--cc=kuznet@virtuozzo.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.