Linux 7.3 extends RWF_DONTCACHE to block devices. It lets an application request buffered I/O with dropbehind cleanup, reducing retention of data that will not be reused. This is not direct I/O and does not guarantee an empty cache when a system call returns.
What actually landed
The block merge includes task-context completion infrastructure and dropbehind writeback work. The block-device operations advertise the new support through FOP_DONTCACHE.
This matters for applications addressing a block device directly. It is distinct from a database storing ordinary files on a filesystem, whose supported I/O path must be checked separately.
“Drop after use” has conditions
The page-cache implementation checks whether a folio is dirty or still under writeback before invalidating it. The completion path also considers execution context and whether it can acquire the folio lock. Some cases skip invalidation.
For writes, application completion and storage writeback are not the same event. A buffered write can finish copying data into memory before the data's writeback finishes. The earlier article's claim that all touched pages disappear immediately after every operation was therefore too strong.
Requesting dropbehind also does not replace the application's durability requirements. Cache retention, direct-versus-buffered I/O and the point at which data is durably stored are separate questions.
Two access patterns can want opposite behavior
Imagine reading a large sequence of records once to compute a checksum. Keeping all those records afterward may offer little reuse. Now imagine repeatedly reading the same small index. Retaining those pages can avoid future storage reads.
Both operations are “reads,” but that label does not describe their cache value. A per-operation request can express the distinction more precisely than assuming every access from one application should have identical treatment.
This example predicts no speedup. On a real system, concurrency, existing cached pages, storage latency and reclaim pressure all affect the result.
Put the early measurements in context
In a February RFC, Tal Zussman reported read and write tests on one virtual machine's block device and explicitly warned about noise. Those are early proposal measurements, not a new benchmark of the final Linux 7.3 implementation.
For evaluation, use a dedicated disposable test device and compare the same data size, reuse pattern, memory limit and durability settings. Record latency distribution, throughput and CPU cost. A gain caused by changing what “write completed” means is not a like-for-like cache optimization. We have not run storage tests or issued writes to a raw device for this article.
Explain best-effort dropbehind and writeback timing from the code; keep early VM results separate from the merged implementation and O_DIRECT.