Don’t let LVM cache metadata eat your write performance

Technical Briefing | 10/14/2026

You added a fast NVMe drive to your LVM setup to act as a write-back cache, thinking you had just bought yourself a massive performance boost. I did the same thing three years ago. Everything felt snappy until the write-back policy kicked in and the kernel started flushing dirty blocks. Suddenly, my IO wait spiked, and the entire system ground to a halt.

Why the default policy is lying to you

Most documentation glosses over how the cache pool actually handles metadata. If you use write-back caching, LVM tracks what is modified in the cache pool itself. When the cache gets full or the flush threshold is hit, the device mapper has to stop and reconcile the metadata. This isn’t just a background task; it becomes a synchronous bottleneck for your application IO if your block size or commit interval isn’t tuned.

lvs -a -o +cache_mode,cache_policy,cache_settings

• Check your current cache settings because the default commit interval is often set to one second, which is way too aggressive for high-latency backing disks.
• Consider moving to write-through caching if your database IO is random and heavy, as it avoids the metadata sync storm entirely.
• Verify if your cache pool is actually smaller than the working set of your application, otherwise you are just paying for a thrashing buffer.

Tuning the commit interval

You can actually adjust the commit interval on the fly without unmounting the volume. Increasing the migration threshold can often stop the kernel from constantly trying to promote and demote blocks while the system is under heavy load. If you are seeing high latency, bump the migration threshold and watch the IO wait graphs flatten out.

If you are still seeing massive stalls after tweaking these values, dump your current device mapper table. Sometimes the problem isn’t the cache policy, but the fact that the underlying physical extents on your backing disk are heavily fragmented. Checking dm-stats might show you exactly where the block contention is happening before you lose another afternoon to troubleshooting.