[PATCH 10/10] tmpfs: add support for multigrain timestamps

2024-06-26 Thread Jeff Layton
Enable multigrain timestamps, which should ensure that there is an apparent change to the timestamp whenever it has been written after being actively observed via getattr. tmpfs only requires the FS_MGTIME flag. Signed-off-by: Jeff Layton --- mm/shmem.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 09/10] btrfs: convert to multigrain timestamps

2024-06-26 Thread Jeff Layton
Enable multigrain timestamps, which should ensure that there is an apparent change to the timestamp whenever it has been written after being actively observed via getattr. Beyond enabling the FS_MGTIME flag, this patch eliminates update_time_for_write, which goes to great pains to avoid in-memory

[PATCH 08/10] ext4: switch to multigrain timestamps

2024-06-26 Thread Jeff Layton
Enable multigrain timestamps, which should ensure that there is an apparent change to the timestamp whenever it has been written after being actively observed via getattr. For ext4, we only need to enable the FS_MGTIME flag. Signed-off-by: Jeff Layton --- fs/ext4/super.c | 2 +- 1 file changed,

[PATCH 07/10] xfs: switch to multigrain timestamps

2024-06-26 Thread Jeff Layton
Enable multigrain timestamps, which should ensure that there is an apparent change to the timestamp whenever it has been written after being actively observed via getattr. Also, anytime the mtime changes, the ctime must also change, and those are now the only two options for xfs_trans_ichgtime. Ha

[PATCH 06/10] fs: have setattr_copy handle multigrain timestamps appropriately

2024-06-26 Thread Jeff Layton
The setattr codepath is still using coarse-grained timestamps, even on multigrain filesystems. To fix this, we need to fetch the timestamp for ctime updates later, at the point where the assignment occurs in setattr_copy. On a multigrain inode, ignore the ia_ctime in the attrs, and always update t

[PATCH 05/10] fs: add percpu counters to count fine vs. coarse timestamps

2024-06-26 Thread Jeff Layton
Keep a pair of percpu counters so we can track what proportion of timestamps is fine-grained. Signed-off-by: Jeff Layton --- fs/inode.c | 39 +++ 1 file changed, 39 insertions(+) diff --git a/fs/inode.c b/fs/inode.c index 12790a26102c..18a9d1398773 100644 ---

[PATCH 04/10] fs: add infrastructure for multigrain timestamps

2024-06-26 Thread Jeff Layton
The VFS always uses coarse-grained timestamps when updating the ctime and mtime after a change. This has the benefit of allowing filesystems to optimize away a lot metadata updates, down to around 1 per jiffy, even when a file is under heavy writes. Unfortunately, this has always been an issue whe

[PATCH 03/10] fs: tracepoints for inode_needs_update_time and inode_set_ctime_to_ts

2024-06-26 Thread Jeff Layton
Add a new tracepoint for when we're testing whether the timestamps need updating, and around the update itself. Signed-off-by: Jeff Layton --- fs/inode.c | 4 +++ include/trace/events/timestamp.h | 76 2 files changed, 80 insertions

[PATCH 02/10] fs: uninline inode_get_ctime and inode_set_ctime_to_ts

2024-06-26 Thread Jeff Layton
Move both functions to fs/inode.c as they have grown a little large for inlining. Signed-off-by: Jeff Layton --- fs/inode.c | 25 + include/linux/fs.h | 13 ++--- 2 files changed, 27 insertions(+), 11 deletions(-) diff --git a/fs/inode.c b/fs/inode.c inde

[PATCH 01/10] fs: turn inode ctime fields into a single ktime_t

2024-06-26 Thread Jeff Layton
The ctime is not settable to arbitrary values. It always comes from the system clock, so we'll never stamp an inode with a value that can't be represented there. If we disregard people setting their system clock past the year 2262, there is no reason we can't replace the ctime fields with a ktime_t

[PATCH 00/10] fs: multigrain timestamp redux

2024-06-26 Thread Jeff Layton
| 2 +- include/linux/fs.h | 61 +++ include/trace/events/timestamp.h | 173 ++ mm/shmem.c | 2 +- 12 files changed, 514 insertions(+), 79 deletions(-) --- base-commit: 33b321ac3a51e590225585f41c7412b86e987a0d change-id: 2024