# Linux 7.5 adds statx flag to expose per-file multi-grain timestamp status

> **Key takeaway:** A new STATX_ATTR_MULTIGRAIN_TIMESTAMP attribute will let user-space applications query whether individual files use fine-grained or coarse-grained timestamp reporting.

**Published:** 2026-11-09T11:08:22+00:00 
**Source:** Phoronix Benchmarks & Drivers 
**Category:** kernel-os 
**Canonical URL:** https://fosswire.org/news/linux-75-adds-statx-flag-to-expose-per-file-multi-grain-time.html 

## Summary
Linux 7.5 will introduce a new statx attribute that exposes whether a file's timestamps are operating in multi-grain mode, closing a visibility gap that has existed since the feature debuted in Linux 6.13. The STATX_ATTR_MULTIGRAIN_TIMESTAMP flag, developed by Jeff Layton, allows user-space programs to determine on a per-file basis whether change and modification times are reported with fine-grained precision or limited to once-per-jiffy coarseness.

Multi-grain timestamps were originally merged in 2024 to address NFS caching problems by allowing systems to trade timestamp accuracy for reduced update overhead. Until now, applications had no reliable mechanism to detect which mode was active for a given file, complicating software that depends on precise mtime or ctime behavior for cache invalidation, build systems, or distributed filesystem consistency.

## VFS and statx interface changes
- **New statx attribute:** The STATX_ATTR_MULTIGRAIN_TIMESTAMP flag indicates whether a file's timestamps use multi-grain reporting, exposing kernel state that was previously invisible to user-space.
- **Per-file granularity:** The attribute operates on individual files rather than filesystem-wide, matching the original multi-grain timestamp design that allows mode switching per inode.
- **VFS integration:** The patch has been queued in the VFS.git tree, placing it on the standard path for inclusion in the Linux 7.5 merge window.
- **Historical context:** Multi-grain timestamp support first landed in Linux 6.13 (2024) to let the kernel toggle between coarse once-per-jiffy timestamps and finer-grained updates, primarily targeting NFS caching scenarios where excessive timestamp precision caused invalidation storms.

## Why it matters
Build systems, package managers, and distributed storage tools that rely on mtime comparisons for cache correctness can now adapt their behavior when coarse timestamps are in use, avoiding false staleness detections or unnecessary rebuilds. For Linux distribution maintainers and enterprise storage administrators, this visibility reduces operational guesswork when debugging timestamp-dependent failures across NFS or other network filesystem deployments.