--- title: When a Small Change Writes Too Much – How A Linux Kernel... description: A deep investigation into a mysterious disk-write burst problem affecting PXC/Galera clusters after upgrading from Debian 11 (Linux 5.10) to Debian 12 (Linux... canonical: https://daily.dev/posts/when-a-small-change-writes-too-much-how-a-linux-kernel-improvement-can-strike-you-in-pxc-galera-wo-vxyblstth twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: When a Small Change Writes Too Much – How A Linux Kernel Improvement Can Strike You in PXC/Galera Workloads | daily.dev og:description: A deep investigation into a mysterious disk-write burst problem affecting PXC/Galera clusters after upgrading from Debian 11 (Linux 5.10) to Debian 12 (Linux... og:url: https://daily.dev/posts/when-a-small-change-writes-too-much-how-a-linux-kernel-improvement-can-strike-you-in-pxc-galera-wo-vxyblstth og:image: https://api.daily.dev/og/posts/vXyBLSTTh.png og:image:alt: When a Small Change Writes Too Much – How A Linux Kernel Improvement Can Strike You in PXC/Galera Workloads og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # When a Small Change Writes Too Much – How A Linux Kernel Improvement Can Strike You in PXC/Galera Workloads **[Percona Blog](https://daily.dev/sources/percona)** · 7 min read · 10 upvotes · 0 comments ## Summary A deep investigation into a mysterious disk-write burst problem affecting PXC/Galera clusters after upgrading from Debian 11 (Linux 5.10) to Debian 12 (Linux 6.1). The root cause traces to the Linux kernel's 'page folios' feature, introduced for faster memory management on XFS filesystems starting in kernel 5.18. Because Galera's writeset cache (gcache) uses mmap() rather than write()/pwrite(), it cannot benefit from a kernel 6.6 fix that added per-block dirty tracking for regular file writes. As a result, small random writes to the mmapped gcache file can trigger writeback of entire large folios (up to 2MB) instead of just the 4KB block that changed, causing massive write amplification. The same underlying issue affects systemd's journal and other mmap-using applications. Workarounds include avoiding large folios via disk readahead settings, disabling transparent huge pages, or switching Galera's cache implementation away from mmap in future versions. The author filed a bug report with Percona (PXC-5340) and shares diagnostic commands to detect the issue. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did disk write bursts start happening on my PXC/Galera cluster after upgrading from Debian 11 to Debian 12? The jump from Linux kernel 5.10 to 6.1 introduces large folios for page cache on XFS, and Galera's gcache file uses mmap() instead of write()/pwrite(). Because mmap writes can only track dirty state at the whole-folio level (up to 2MB) rather than the 4KB filesystem block, small random writes to the cache can flush entire folios, causing massive write amplification during writeback. _Teams chasing kernel-upgrade regressions in database clusters track root-cause writeups like this on daily.dev._ ### Why do large folios cause more write amplification for mmap() files than for files using write() or pwrite()? Starting in Linux 6.6, a kernel patch added per-block dirty tracking via iomap for write()/pwrite() paths, letting writeback sync only the exact filesystem block that changed. The mmap() path never got this improvement, so any dirty byte inside a mapped folio still forces the whole folio (up to 2MB with large readahead) to be written back, unlike the 4KB granularity available to regular writes. _Developers debugging IO amplification on mmapped files can keep up with kernel internals like this via daily.dev._ ### How can I detect if large folios are causing write amplification on my mmap-backed database cache file? Check read_ahead_kb and optimal_io_size for the block device, since larger readahead values allow bigger folios up to 2MB. Monitor FilePmdMapped in /proc/meminfo or smaps for the mapped file, watch thp_file_mapped in /proc/vmstat, and use pidstat -d to see per-thread IO charges occurring in up-to-2MB multiples during writeback. _Engineers diagnosing mysterious IO spikes on mmapped files can find practical detection steps like these via daily.dev._ ## Similar posts on daily.dev - [Too many GCache Page Files in MySQL Data Directory](https://daily.dev/posts/too-many-gcache-page-files-in-mysql-data-directory-0ybssc1w5) · Planet MySQL · 2 upvotes · 0 comments - [Linux 6.19 To Allow File-Systems To Increase The Writeback Chunk Size](https://daily.dev/posts/linux-6-19-to-allow-file-systems-to-increase-the-writeback-chunk-size-bzrmbrhmp) · Phoronix · 0 upvotes · 0 comments - [Excessive IO caused by systemd-journald · Issue \#40262 · systemd/systemd](https://daily.dev/posts/excessive-io-caused-by-systemd-journald-issue-40262-systemd-systemd-og4rnygfu) · Hacker News · 0 upvotes · 0 comments - [Someone moved three lines of code in Linux 7.2 and got a 5% storage speed boost](https://daily.dev/posts/someone-moved-three-lines-of-code-in-linux-7-2-and-got-a-5-storage-speed-boost-4juxmldkx) · XDA Developers · 0 upvotes · 0 comments --- Tags: [#linux](https://daily.dev/tags/linux), [#mysql](https://daily.dev/tags/mysql) [View this post on daily.dev](https://daily.dev/posts/when-a-small-change-writes-too-much-how-a-linux-kernel-improvement-can-strike-you-in-pxc-galera-wo-vxyblstth) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"When a Small Change Writes Too Much – How A Linux Kernel Improvement Can Strike You in PXC/Galera Workloads","url":"https://daily.dev/posts/when-a-small-change-writes-too-much-how-a-linux-kernel-improvement-can-strike-you-in-pxc-galera-wo-vxyblstth","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/when-a-small-change-writes-too-much-how-a-linux-kernel-improvement-can-strike-you-in-pxc-galera-wo-vxyblstth"},"datePublished":"2026-10-16T14:02:27.055Z","dateModified":"2026-10-16T14:04:18.618Z","description":"A deep investigation into a mysterious disk-write burst problem affecting PXC/Galera clusters after upgrading from Debian 11 (Linux 5.10) to Debian 12 (Linux...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/acf526c90b6c1773527f3c641f769fa6?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/acf526c90b6c1773527f3c641f769fa6?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Percona Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Percona Blog","logo":"https://media.daily.dev/image/upload/s--Lb3XkBh3--/f_auto,q_auto/v1780213412/logos/percona?_a=BAMAMiWQ0","url":"https://daily.dev/sources/percona"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/when-a-small-change-writes-too-much-how-a-linux-kernel-improvement-can-strike-you-in-pxc-galera-wo-vxyblstth","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,mysql","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Percona Blog","item":"https://daily.dev/sources/percona"},{"@type":"ListItem","position":3,"name":"When a Small Change Writes Too Much – How A Linux Kernel Improvement Can Strike You in PXC/Galera Workloads"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/when-a-small-change-writes-too-much-how-a-linux-kernel-improvement-can-strike-you-in-pxc-galera-wo-vxyblstth#faq","mainEntity":[{"@type":"Question","name":"Why did disk write bursts start happening on my PXC/Galera cluster after upgrading from Debian 11 to Debian 12?","acceptedAnswer":{"@type":"Answer","text":"The jump from Linux kernel 5.10 to 6.1 introduces large folios for page cache on XFS, and Galera's gcache file uses mmap() instead of write()/pwrite(). Because mmap writes can only track dirty state at the whole-folio level (up to 2MB) rather than the 4KB filesystem block, small random writes to the cache can flush entire folios, causing massive write amplification during writeback. Teams chasing kernel-upgrade regressions in database clusters track root-cause writeups like this on daily.dev."}},{"@type":"Question","name":"Why do large folios cause more write amplification for mmap() files than for files using write() or pwrite()?","acceptedAnswer":{"@type":"Answer","text":"Starting in Linux 6.6, a kernel patch added per-block dirty tracking via iomap for write()/pwrite() paths, letting writeback sync only the exact filesystem block that changed. The mmap() path never got this improvement, so any dirty byte inside a mapped folio still forces the whole folio (up to 2MB with large readahead) to be written back, unlike the 4KB granularity available to regular writes. Developers debugging IO amplification on mmapped files can keep up with kernel internals like this via daily.dev."}},{"@type":"Question","name":"How can I detect if large folios are causing write amplification on my mmap-backed database cache file?","acceptedAnswer":{"@type":"Answer","text":"Check read_ahead_kb and optimal_io_size for the block device, since larger readahead values allow bigger folios up to 2MB. Monitor FilePmdMapped in /proc/meminfo or smaps for the mapped file, watch thp_file_mapped in /proc/vmstat, and use pidstat -d to see per-thread IO charges occurring in up-to-2MB multiples during writeback. Engineers diagnosing mysterious IO spikes on mmapped files can find practical detection steps like these via daily.dev."}}]} ```