This set is essentially unchanged from the last one, aside from the
new file in Documentation/. I had a review comment from Andi Kleen
suggesting that the ctime_floor should be per time_namespace, but I
think that's incorrect as the realtime clock is not namespaced.
At LSF/MM this year, we had a d
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
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
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
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
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 | 38 ++
1 file changed, 38 insertions(+)
diff --git a/fs/inode.c b/fs/inode.c
index 12790a26102c..5b5a1a8c0bb7 100644
---
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
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
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,
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
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
Add a high-level document that describes how multigrain timestamps work,
rationale for them, and some info about implementation and tradeoffs.
Signed-off-by: Jeff Layton
---
Documentation/filesystems/multigrain-ts.rst | 126
1 file changed, 126 insertions(+)
diff --
On Mon, Jul 01, 2024 at 06:26:43AM -0400, Jeff Layton wrote:
> 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 ch
On Mon, Jul 01, 2024 at 06:26:45AM -0400, Jeff Layton wrote:
> 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 eliminat
On Mon, Jul 01, 2024 at 06:26:47AM -0400, Jeff Layton wrote:
> Add a high-level document that describes how multigrain timestamps work,
> rationale for them, and some info about implementation and tradeoffs.
>
> Signed-off-by: Jeff Layton
> ---
> Documentation/filesystems/multigrain-ts.rst | 126
On Mon, Jul 01, 2024 at 06:26:36AM -0400, Jeff Layton wrote:
> This set is essentially unchanged from the last one, aside from the
> new file in Documentation/. I had a review comment from Andi Kleen
> suggesting that the ctime_floor should be per time_namespace, but I
> think that's incorrect as t
On Mon, 2024-07-01 at 09:49 -0400, Josef Bacik wrote:
> On Mon, Jul 01, 2024 at 06:26:45AM -0400, Jeff Layton wrote:
> > 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
On Mon, 2024-07-01 at 09:53 -0400, Josef Bacik wrote:
> On Mon, Jul 01, 2024 at 06:26:36AM -0400, Jeff Layton wrote:
> > This set is essentially unchanged from the last one, aside from the
> > new file in Documentation/. I had a review comment from Andi Kleen
> > suggesting that the ctime_floor sho
On Mon, Jul 01, 2024 at 09:57:43AM -0400, Jeff Layton wrote:
> On Mon, 2024-07-01 at 09:49 -0400, Josef Bacik wrote:
> > On Mon, Jul 01, 2024 at 06:26:45AM -0400, Jeff Layton wrote:
> > > Enable multigrain timestamps, which should ensure that there is an
> > > apparent change to the timestamp whene
On Mon, Jul 01, 2024 at 09:57:43AM -0400, Jeff Layton wrote:
> On Mon, 2024-07-01 at 09:49 -0400, Josef Bacik wrote:
> > On Mon, Jul 01, 2024 at 06:26:45AM -0400, Jeff Layton wrote:
> > > Enable multigrain timestamps, which should ensure that there is an
> > > apparent change to the timestamp whene
On Wed, Jun 26, 2024 at 09:00:21PM -0400, Jeff Layton wrote:
> 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
On Mon, 2024-07-01 at 15:49 -0700, Darrick J. Wong wrote:
> On Wed, Jun 26, 2024 at 09:00:21PM -0400, Jeff Layton wrote:
> > 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 w
22 matches
Mail list logo
