On Thu, Jul 11, 2024 at 07:08:04AM -0400, Jeff Layton wrote: > tl;dr for those who have been following along: > > There are several changes in this version. The conversion of ctime to > be a ktime_t value has been dropped, and we now use an unused bit in > the nsec field as the QUERIED flag (like the earlier patchset did). > > The floor value is now tracked as a monotonic clock value, and is > converted to a realtime value on an as-needed basis. This eliminates the > problem of trying to detect when the realtime clock jumps backward. > > Longer patch description for those just joining in: > > 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 [1]. > > 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 per-time_namespace > ctime_floor value that should prevent this from occurring. In the above > situation, 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 is in the process of > being merged. > > The testing I've done seems to show performance parity with multigrain > timestamps enabled vs. disabled, 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 have this considered for v6.12, > after a nice long full-cycle soak in linux-next. > > PS: I took a stab at a conversion for bcachefs too, but it's not > trivial. bcachefs handles timestamps backward from the way most > block-based filesystems do. Instead of updating them in struct inode and > eventually copying them to a disk-based representation, it does the > reverse and updates the timestamps in its in-core image of the on-disk > inode, and then copies that into struct inode. Either that will need to > be changed, or we'll need to come up with a different way to do this for > bcachefs. > > [1]: https://lore.kernel.org/linux-fsdevel/20230807-mgctime-v7-0-d1dec143a704@xxxxxxxxxx/ > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx> Thanks, Josef
