Multi-grain(ed) timestamps had been submitted for Linux 6.6 to better deal with NFS where the once-per-jiffy coarse-grained timestamps aren't enough for (in)validating caches. Multi-grained timestamps sought to address that by optionally allowing for the more fine-grained timestamps when desired but not using that finer granularity everywhere due to the greater overhead costs. This feature though ended up being reverted weeks later due to subtle bugs being uncovered. Now though a new redux patch series has been posted for providing another attempt at multi-grained timestamps.

Jeff Layton today sent out the updated nulti-grain timestamp patches. The key change is address the shortcomings discovered from this code during its short time in Linux 6.6:

"The original merge of multigrain timestamps for v6.6 had to be reverted, as a file with a coarse-grained timestamp could incorrectly appear to be modified before a file with a fine-grained timestamp, when that wasn't the case.

This revision solves that problem by making it so that when a fine-grained timespec64 is handed out, that that value becomes the floor for further coarse-grained timespec64 fetches. This requires new timekeeper interfaces with a potential downside: when a file is stamped with a fine-grained timestamp, it has to (briefly) take the global timekeeper spinlock.

Because of that, this set takes greater pains to avoid issuing new fine-grained timestamps when possible. A fine-grained timestamp is now only required if the current mtime or ctime have been fetched for a getattr, and the next coarse-grained tick has not happened yet. For any other case, a coarse-grained timestamp is fine, and that is done using the seqcount."

These new patches for multi-grained timestamps have been posted under a "request for comments" flag, so we'll see what other upstream Linux kernel stakeholders think of its improvements and if it ends up being enough to get it re-landed into the mainline Linux kernel in the near-term.