Stale page cache reads after file truncation on local filesystems

Direct answer

On local filesystems, ftruncate() normally removes page‑cache pages beyond the new size. Deferred invalidation is not the default for MAP_PRIVATE mappings; it is primarily observed with MAP_SHARED mappings on filesystems that delay block allocation or writeback, and when dirty pages have not yet been flushed. Kernel version influences how promptly the truncate path zaps shared pages, but the practical trigger is the combination of a shared mapping, unwritten dirty data, and low writeback or reclaim pressure.

Established behavior versus conditional behavior

Established on standard local filesystems:

• MAP_PRIVATE mappings do not expose pre‑truncate bytes after ftruncate(); the kernel unmaps or copy‑on‑writes the affected ranges.
• MAP_SHARED mappings alias the page cache directly, so any page that survives truncation remains readable through the mapping.

Conditional and configuration‑dependent:

• Filesystems that delay block allocation or writeback (for example, ext4 with delalloc, XFS, btrfs) can keep truncated regions backed by dirty pages that have not yet been flushed.
• Dirty‑page thresholds such as vm.dirty_ratio and vm.dirty_background_ratio control how long those pages persist; higher values widen the window.
• Kernel version affects the truncate invalidation path, but exact boundaries vary with distribution backports and should be verified on the target system rather than assumed from a specific release cutoff.

How shared mappings change visibility

With MAP_SHARED, the mapping is a direct window into the file's page cache. If ftruncate() shrinks the file but the kernel leaves the tail pages resident—because they are dirty, under writeback, or not yet reclaimed—a read through the mapping still sees the old bytes. The data is not restored from disk; it is the same in‑memory page that was present before the truncate. MAP_PRIVATE avoids this because the kernel severs the connection to those pages during truncation.

Steps to confirm and resolve

1. Check the mapping type in the application. If it is MAP_SHARED, the risk exists.
2. Identify the filesystem and mount options. If delayed allocation is active (for example, ext4 delalloc or XFS), dirty pages can outlive the truncate.
3. Inspect dirty limits with sysctl vm.dirty_ratio vm.dirty_background_ratio.
4. Reproduce with a minimal test: create a file, write known data, mmap it MAP_SHARED, ftruncate to a smaller size, and read the tail through the mapping.
5. Compare with MAP_PRIVATE; stale data should not appear.
6. If stale data is confirmed, force writeback with msync(addr, len, MS_SYNC) before truncating, or invalidate after truncation with msync(addr, len, MS_INVALIDATE) where supported. Dropping caches or inducing reclaim pressure can confirm the diagnosis but are not production fixes.

Diagnostic detail that changes the recommendation

The single most useful missing detail is the filesystem type and mount options. On ext4 with nodelalloc or on a filesystem that allocates blocks eagerly, the stale‑page window is typically negligible. On ext4 with delalloc, XFS, or btrfs, the recommendation shifts toward explicit msync discipline or avoiding MAP_SHARED for files that are truncated concurrently.