Multi-Grain Timestamps Revived For Linux File-Systems
([Linux Storage] 16 Minutes Ago
Multi-Grain Timestamps)
- Reference: 0001473663
- News link: https://www.phoronix.com/news/Multi-Grain-Timestamps-Revived
- Source link:
Last year a new kernel feature merged in Linux 6.6 was [1]multi-grain(ed) timestamps for file-systems as a means of better timestamp handling originally for NFS compared to the existing coarse-grained timestamps with the once per jiffy timestamps being used for invalidating NFS caches. But [2]multi-grain timestamps was reverted just weeks after landing in the mainline kernel due to corner cases like a newer file with a coarse-grained timestamp appearing earlier than another file with a fine-grained timestamp. Due to subtle bugs like that, multi-grain timestamps were dropped before Linux 6.6 was even released while now there is a revised attempt.
Jeff Layton has sent out a new patch series aiming to revive multi-grain timestamps for Linux file-systems while addressing the earlier design issues. Layton explained in [3]the new patch series of this multi-grain timestamp revival:
"At LSF/MM this year, we had a discussion about the inode change attribute. At the time I mentioned that I thought I could salvage the multigrain timestamp work that had to be reverted last year. That version had to be reverted because it was possible for a file to get a coarse grained timestamp that appeared to be earlier than another file that had recently gotten a fine-grained stamp.
This version corrects the problem by establishing a global ctime_floor value that should prevent this from occurring. In the above situation that was problematic before, the two files might end up with the same timestamp value, but they won't appear to have been modified in the wrong order.
That problem was discovered by the test-stat-time gnulib test. Note that that test still fails on multigrain timestamps, but that's because its method of determining the minimum delay that will show a timestamp change will no longer work with multigrain timestamps. I have a patch to change the testcase to use a different method that I will post soon.
The big question with this set is whether the performance will be suitable. The testing I've done seems to show performance parity with multigrain timestamps enabled, but it's hard to rule this out regressing some workload.
This set is based on top of Christian's vfs.misc branch (which has the earlier change to track inode timestamps as discrete integers). If there are no major objections, I'd like to let this soak in linux-next for a bit to see if any problems shake out."
We'll see how the attempt goes this time if multi-grain timestamps can be safely reintroduced to the mainline kernel.
[1] https://www.phoronix.com/news/Multi-Grained-Timestamps
[2] https://www.phoronix.com/news/Linux-Revert-MG-Timestamps
[3] https://lore.kernel.org/lkml/20240626-mgtime-v1-0-a189352d0f8f@kernel.org/
Jeff Layton has sent out a new patch series aiming to revive multi-grain timestamps for Linux file-systems while addressing the earlier design issues. Layton explained in [3]the new patch series of this multi-grain timestamp revival:
"At LSF/MM this year, we had a discussion about the inode change attribute. At the time I mentioned that I thought I could salvage the multigrain timestamp work that had to be reverted last year. That version had to be reverted because it was possible for a file to get a coarse grained timestamp that appeared to be earlier than another file that had recently gotten a fine-grained stamp.
This version corrects the problem by establishing a global ctime_floor value that should prevent this from occurring. In the above situation that was problematic before, the two files might end up with the same timestamp value, but they won't appear to have been modified in the wrong order.
That problem was discovered by the test-stat-time gnulib test. Note that that test still fails on multigrain timestamps, but that's because its method of determining the minimum delay that will show a timestamp change will no longer work with multigrain timestamps. I have a patch to change the testcase to use a different method that I will post soon.
The big question with this set is whether the performance will be suitable. The testing I've done seems to show performance parity with multigrain timestamps enabled, but it's hard to rule this out regressing some workload.
This set is based on top of Christian's vfs.misc branch (which has the earlier change to track inode timestamps as discrete integers). If there are no major objections, I'd like to let this soak in linux-next for a bit to see if any problems shake out."
We'll see how the attempt goes this time if multi-grain timestamps can be safely reintroduced to the mainline kernel.
[1] https://www.phoronix.com/news/Multi-Grained-Timestamps
[2] https://www.phoronix.com/news/Linux-Revert-MG-Timestamps
[3] https://lore.kernel.org/lkml/20240626-mgtime-v1-0-a189352d0f8f@kernel.org/
phoronix