From: Damien Le Moal <dlemoal@kernel.org>
To: linux-xfs@vger.kernel.org, Carlos Maiolino <cem@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Hans Holmberg <hans.holmberg@wdc.com>
Subject: [PATCH] xfs: do not tight-pack write large files
Date: Mon, 13 Oct 2025 15:45:12 +0900 [thread overview]
Message-ID: <20251013064512.752089-1-dlemoal@kernel.org> (raw)
The tick-packing data block allocation which writes blocks of closed
files in the same zone is very efficient at improving write performance
on HDDs by reducing, and even suppressing, disk head seeks. However,
such tight packing does not make sense for large files that require at
least a full realtime block group (i.e. a zone). If tight-packing
placement is applied for such files, the VM writeback thread switching
between inodes result in the large file to be fragmented, thus
increasing the garbage collection penalty later when the used realtime
block group/zone needs to be reclaimed.
This problem can be avoided with a simple heuristic: if the size of the
inode being written back is at least equal to the realtime block group
size, do not use tight-packing. Modify xfs_zoned_pack_tight() to always
return false in this case.
With this change, a multi-writer workload writing files of 256 MB on a
file system backed by an SMR HDD with 256 MB zone size sees all files
occupying exactly one zone, thus completely removing the heavy
fragmentation observed without this change.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
---
fs/xfs/xfs_zone_alloc.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/xfs/xfs_zone_alloc.c b/fs/xfs/xfs_zone_alloc.c
index 1147bacb2da8..c51788550c7c 100644
--- a/fs/xfs/xfs_zone_alloc.c
+++ b/fs/xfs/xfs_zone_alloc.c
@@ -622,6 +622,17 @@ static inline enum rw_hint xfs_inode_write_hint(struct xfs_inode *ip)
*/
static inline bool xfs_zoned_pack_tight(struct xfs_inode *ip)
{
+ struct xfs_mount *mp = ip->i_mount;
+ size_t zone_capacity =
+ XFS_FSB_TO_B(mp, mp->m_groups[XG_TYPE_RTG].blocks);
+
+ /*
+ * Do not pack tight large files that are already using a full group
+ * (zone) to avoid fragmentation.
+ */
+ if (i_size_read(VFS_I(ip)) >= zone_capacity)
+ return false;
+
return !inode_is_open_for_write(VFS_I(ip)) &&
!(ip->i_diflags & XFS_DIFLAG_APPEND);
}
--
2.51.0
next reply other threads:[~2025-10-13 6:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 6:45 Damien Le Moal [this message]
2025-10-13 7:09 ` [PATCH] xfs: do not tight-pack write large files 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=20251013064512.752089-1-dlemoal@kernel.org \
--to=dlemoal@kernel.org \
--cc=cem@kernel.org \
--cc=hans.holmberg@wdc.com \
--cc=hch@lst.de \
--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 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.