On Wed, 2024-07-17 at 13:31 +0200, Jan Kara wrote:
> On Mon 15-07-24 08:48:56, Jeff Layton wrote:
> > Add a high-level document that describes how multigrain timestamps work,
> > rationale for them, and some info about implementation and tradeoffs.
> >
> > Reviewed-by:
On Tue, 2024-07-16 at 09:37 +0200, Christian Brauner wrote:
> On Mon, Jul 15, 2024 at 08:48:51AM GMT, Jeff Layton wrote:
> > I think this is pretty much ready for linux-next now. Since the latest
> > changes are pretty minimal, I've left the Reviewed-by's intact. It would
On Mon, 2024-07-15 at 11:32 -0700, Darrick J. Wong wrote:
> On Mon, Jul 15, 2024 at 08:48:54AM -0400, Jeff Layton wrote:
> > Four percpu counters for counting various stats around mgtimes, and
> > a
> > new debugfs file for displaying them:
> >
> > - number of att
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.
Reviewed-by: Josef Bacik
Signed-off-by: Jeff Layton
---
mm/shmem.c | 2 +-
1 file
stores. Just have it overwrite the timestamps unconditionally.
Note that this also drops the IS_I_VERSION check and unconditionally
bumps the change attribute, since SB_I_VERSION is always set on btrfs.
Reviewed-by: Josef Bacik
Signed-off-by: Jeff Layton
---
fs/btrfs/file.c | 25
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.
Reviewed-by: Josef Bacik
Signed-off-by: Jeff Layton
---
fs/ext4
. Have that function
unconditionally bump the ctime, and ASSERT that XFS_ICHGTIME_CHG is
always set.
Finally, stop setting STATX_CHANGE_COOKIE in getattr, since the ctime
should give us better semantics now.
Reviewed-by: Josef Bacik
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_trans_inode.c
Add a high-level document that describes how multigrain timestamps work,
rationale for them, and some info about implementation and tradeoffs.
Reviewed-by: Josef Bacik
Signed-off-by: Jeff Layton
---
Documentation/filesystems/multigrain-ts.rst | 120
1 file changed
cit update
elsewhere before updating the local inode.
Reviewed-by: Darrick J. Wong
Reviewed-by: Josef Bacik
Signed-off-by: Jeff Layton
---
fs/attr.c | 52 ++--
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/fs/attr.c b/fs/at
-by: Jeff Layton
---
fs/inode.c | 70 +-
1 file changed, 69 insertions(+), 1 deletion(-)
diff --git a/fs/inode.c b/fs/inode.c
index 869994285e87..fff844345c35 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -21,6 +21,8 @@
#include
#include
Add some tracepoints around various multigrain timestamp events.
Reviewed-by: Josef Bacik
Signed-off-by: Jeff Layton
---
fs/inode.c | 9 ++-
fs/stat.c| 3 +
include/trace/events/timestamp.h | 124 +++
3 files
the ctime swap whether it succeeds or fails, since
either is just as valid.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Reviewed-by: Darrick J. Wong
Reviewed-by: Josef
after the merge window settles?
Thanks!
Signed-off-by: Jeff Layton
---
Changes in v6:
- Normalize timespec64 in inode_set_ctime_to_ts
- use DEFINE_PER_CPU counters for better vfs consistency
- skip ctime cmpxchg if the result means nothing will change
- add trace_ctime_xchg_skip to track ski
On Thu, 2024-07-11 at 12:14 -0700, Darrick J. Wong wrote:
> On Thu, Jul 11, 2024 at 11:58:59AM -0400, Jeff Layton wrote:
> > On Thu, 2024-07-11 at 08:09 -0700, Darrick J. Wong wrote:
> > > On Thu, Jul 11, 2024 at 07:08:10AM -0400, Jeff Layton wrote:
> > > > Enabl
On Thu, 2024-07-11 at 12:12 -0700, Darrick J. Wong wrote:
> On Thu, Jul 11, 2024 at 07:08:09AM -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.
> &g
On Thu, 2024-07-11 at 09:49 -0700, Darrick J. Wong wrote:
> On Thu, Jul 11, 2024 at 07:08:06AM -0400, Jeff Layton wrote:
> > Add some tracepoints around various multigrain timestamp events.
> >
> > Signed-off-by: Jeff Layton
> > ---
> > fs/inode.c
On Thu, 2024-07-11 at 08:09 -0700, Darrick J. Wong wrote:
> On Thu, Jul 11, 2024 at 07:08:10AM -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
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
stores. Just have it overwrite the timestamps unconditionally.
Note that this also drops the IS_I_VERSION check and unconditionally
bumps the change attribute, since SB_I_VERSION is always set on btrfs.
Signed-off-by: Jeff Layton
---
fs/btrfs/file.c | 25 -
fs/btrfs
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
. Have that function
unconditionally bump the ctime, and ASSERT that XFS_ICHGTIME_CHG is
always set.
Finally, stop setting STATX_CHANGE_COOKIE in getattr, since the ctime
should give us better semantics now.
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_trans_inode.c | 6 +++---
fs/xfs
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 | 120
1 file changed, 120 insertions(+)
diff
cit update
elsewhere before updating the local inode.
Signed-off-by: Jeff Layton
---
fs/attr.c | 52 ++--
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 825007d5cda4..e03ea6951864 100644
--- a/fs/attr.c
+++ b
Four percpu counters for counting various stats around mgtimes, and a
new debugfs file for displaying them:
- number of attempted ctime updates
- number of successful i_ctime_nsec swaps
- number of fine-grained timestamp fetches
- number of floor value swaps
Signed-off-by: Jeff Layton
---
fs
Add some tracepoints around various multigrain timestamp events.
Signed-off-by: Jeff Layton
---
fs/inode.c | 5 ++
fs/stat.c| 3 ++
include/trace/events/timestamp.h | 109 +++
3 files changed, 117 insertions
the ctime swap whether it succeeds or fails, since
either is just as valid.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Signed-off-by:
uct 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-d1dec143a...@kernel.org/
Signed-off-by: Jeff Layton
---
Changes in v5:
- refetch coarse tim
On Mon, 2024-07-08 at 14:51 -0400, Jeff Layton wrote:
> On Mon, 2024-07-08 at 11:47 -0700, Darrick J. Wong wrote:
> > On Mon, Jul 08, 2024 at 11:53:39AM -0400, Jeff Layton wrote:
> > > Enable multigrain timestamps, which should ensure that there is an
> > > appar
On Mon, 2024-07-08 at 11:47 -0700, Darrick J. Wong wrote:
> On Mon, Jul 08, 2024 at 11:53:39AM -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
On Mon, 2024-07-08 at 11:39 -0700, Darrick J. Wong wrote:
> On Mon, Jul 08, 2024 at 11:53:34AM -0400, Jeff Layton wrote:
> > The VFS has always used coarse-grained timestamps when updating the
> > ctime and mtime after a change. This has the benefit of allowing
> > filesyste
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
stores. Just have it overwrite the timestamps unconditionally.
Note that this also drops the IS_I_VERSION check and unconditionally
bumps the change attribute, since SB_I_VERSION is always set on btrfs.
Signed-off-by: Jeff Layton
---
fs/btrfs/file.c | 25 -
fs/btrfs
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
. Have that function
unconditionally bump the ctime, and ASSERT that XFS_ICHGTIME_CHG is
always set.
Finally, stop setting STATX_CHANGE_COOKIE in getattr, since the ctime
should give us better semantics now.
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_trans_inode.c | 6 +++---
fs/xfs
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 | 120
1 file changed, 120 insertions(+)
diff
cit update
elsewhere before updating the local inode.
Signed-off-by: Jeff Layton
---
fs/attr.c | 52 ++--
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 825007d5cda4..e03ea6951864 100644
--- a/fs/attr.c
+++ b
Four percpu counters for counting various stats around mgtimes, and a
new debugfs file for displaying them:
- number of attempted ctime updates
- number of successful i_ctime_nsec swaps
- number of fine-grained timestamp fetches
- number of floor value swaps
Signed-off-by: Jeff Layton
---
fs
Add some tracepoints around various multigrain timestamp events.
Signed-off-by: Jeff Layton
---
fs/inode.c | 5 ++
fs/stat.c| 3 ++
include/trace/events/timestamp.h | 109 +++
3 files changed, 117 insertions
the ctime swap whether it succeeds or fails, since
either is just as valid.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Signed-off-by:
uct 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-d1dec143a...@kernel.org/
Signed-off-by: Jeff Layton
---
Changes in v4:
- reordered tracepoint fields for
On Mon, 2024-07-08 at 08:30 -0400, Jeff Layton wrote:
> On Fri, 2024-07-05 at 13:02 -0400, Jeff Layton wrote:
> > The VFS has always used coarse-grained timestamps when updating the
> > ctime and mtime after a change. This has the benefit of allowing
> > filesystems to optimiz
On Fri, 2024-07-05 at 13:02 -0400, Jeff Layton wrote:
> The VFS has always used 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 wh
On Fri, 2024-07-05 at 14:07 -0400, Steven Rostedt wrote:
> On Fri, 05 Jul 2024 13:02:36 -0400
> Jeff Layton wrote:
>
> > diff --git a/include/trace/events/timestamp.h
> > b/include/trace/events/timestamp.h
> > new file mode 100644
> > index ..a004e55
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
stores. Just have it overwrite the timestamps unconditionally.
Note that this also drops the IS_I_VERSION check and unconditionally
bumps the change attribute, since SB_I_VERSION is always set on btrfs.
Signed-off-by: Jeff Layton
---
fs/btrfs/file.c | 25 -
fs/btrfs
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
. Have that function
unconditionally bump the ctime, and ASSERT that XFS_ICHGTIME_CHG is
always set.
Finally, stop setting STATX_CHANGE_COOKIE in getattr, since the ctime
should give us better semantics now.
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_trans_inode.c | 6 +++---
fs/xfs
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 | 120
1 file changed, 120 insertions(+)
diff
cit update
elsewhere before updating the local inode.
Signed-off-by: Jeff Layton
---
fs/attr.c | 52 ++--
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 825007d5cda4..e03ea6951864 100644
--- a/fs/attr.c
+++ b
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 | 49 -
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/fs/inode.c b/fs/inode.c
index
Add some tracepoints around various multigrain timestamp events.
Signed-off-by: Jeff Layton
---
fs/inode.c | 5 ++
fs/stat.c| 3 ++
include/trace/events/timestamp.h | 109 +++
3 files changed, 117 insertions
the ctime swap whether it succeeds or fails, since
either is just as valid.
Filesystems can opt into this by setting the FS_MGTIME fstype flag.
Others should be unaffected (other than being subject to the same floor
value as multigrain filesystems).
Signed-off-by:
rg
Cc: linux...@kvack.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Jeff Layton
Changes in v3:
- Drop the conversion of i_ctime fields to ktime_t, and use an unused bit
of the i_ctime_nsec field as QUERIED flag.
- Better tracepoints for tracking floor and ctime updat
On Tue, 2024-07-02 at 08:12 -0700, Christoph Hellwig wrote:
> On Tue, Jul 02, 2024 at 08:21:42AM -0400, Jeff Layton wrote:
> > Many of the existing callers of inode_ctime_to_ts are in void
> > return
> > functions. They're just copying data from an internal
> > re
On Tue, 2024-07-02 at 05:15 -0700, Christoph Hellwig wrote:
> On Tue, Jul 02, 2024 at 08:09:46AM -0400, Jeff Layton wrote:
> > > > corrupt timestamps like this?
> > >
> > > inode_set_ctime_to_ts should return an error if things are out of
> > > ran
On Tue, 2024-07-02 at 05:04 -0700, Christoph Hellwig wrote:
> On Tue, Jul 02, 2024 at 07:44:19AM -0400, Jeff Layton wrote:
> > Complaining about it is fairly simple. We could just throw a pr_warn in
> > inode_set_ctime_to_ts when the time comes back as KTIME_MAX. This might
>
On Tue, 2024-07-02 at 12:19 +0200, Jan Kara wrote:
> On Tue 02-07-24 05:56:37, Jeff Layton wrote:
> > On Tue, 2024-07-02 at 00:37 -0700, Christoph Hellwig wrote:
> > > On Mon, Jul 01, 2024 at 08:22:07PM -0400, Jeff Layton wrote:
> > > > 2) the filesystem has bee
On Tue, 2024-07-02 at 00:37 -0700, Christoph Hellwig wrote:
> On Mon, Jul 01, 2024 at 08:22:07PM -0400, Jeff Layton wrote:
> > 2) the filesystem has been altered (fuzzing? deliberate doctoring?).
> >
> > None of these seem like legitimate use cases so I'm arguing that we
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
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
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
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
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
stores. Just have it overwrite the timestamps unconditionally.
Signed-off-by: Jeff Layton
---
fs/btrfs/file.c | 25 -
fs/btrfs/super.c | 3 ++-
2 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index d90138683a0a
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
. Have that function
unconditionally bump the ctime, and ASSERT that XFS_ICHGTIME_CHG is
always set.
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_trans_inode.c | 6 +++---
fs/xfs/xfs_iops.c | 6 --
fs/xfs/xfs_super.c | 2 +-
3 files changed, 8 insertions(+), 6
cit update
elsewhere before updating the local inode.
Signed-off-by: Jeff Layton
---
fs/attr.c | 52 ++--
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 825007d5cda4..e03ea6951864 100644
--- a/fs/attr.c
+++ b
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
rained clock.
Filesystems opt into this by setting the FS_MGTIME fstype flag. One
caveat: those that do will always present ctimes that have the lowest
bit unset, even when the on-disk ctime has it set.
Signed-off-by: Jeff Layton
---
fs/inode.c | 168
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 change
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
ystem. The operating assumption here is that that is not a
practical problem.
Signed-off-by: Jeff Layton
---
include/linux/fs.h | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 2fa06a4d197a..7110d6dc9aab
this soak in linux-next for a
bit to see if any problems shake out.
[1]:
https://lore.kernel.org/linux-fsdevel/20230807-mgctime-v7-0-d1dec143a...@kernel.org/
Signed-off-by: Jeff Layton
---
Changes in v2:
- Added Documentation file
- Link to v1:
https://lore.kernel.org/r/20240626-mgtime-v1-0-
On Thu, 2024-06-27 at 11:02 -0400, Chuck Lever wrote:
> On Wed, Jun 26, 2024 at 09:00:24PM -0400, Jeff Layton wrote:
> > The VFS always uses coarse-grained timestamps when updating the ctime
> > and mtime after a change. This has the benefit of allowing filesystems
> > 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.
tmpfs only requires the FS_MGTIME flag.
Signed-off-by: Jeff Layton
---
mm/shmem.c | 2 +-
1 file changed, 1 insertion
stores. Just have it overwrite the timestamps unconditionally.
Signed-off-by: Jeff Layton
---
fs/btrfs/file.c | 25 -
fs/btrfs/super.c | 3 ++-
2 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index e764ac3f22e2
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
. Have that function
unconditionally bump the ctime, and ASSERT that XFS_ICHGTIME_CHG is
always set.
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_trans_inode.c | 6 +++---
fs/xfs/xfs_iops.c | 6 --
fs/xfs/xfs_super.c | 2 +-
3 files changed, 8 insertions(+), 6
cit update
elsewhere before updating the local inode.
Signed-off-by: Jeff Layton
---
fs/attr.c | 52 ++--
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 825007d5cda4..e03ea6951864 100644
--- a/fs/attr.c
+++ b
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
rained clock.
Filesystems opt into this by setting the FS_MGTIME fstype flag. One
caveat: those that do will always present ctimes that have the lowest
bit unset, even when the on-disk ctime has it set.
Signed-off-by: Jeff Layton
---
fs/inode.c | 168
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 change
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
ystem. The operating assumption here is that that is not a
practical problem.
Signed-off-by: Jeff Layton
---
include/linux/fs.h | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 5ff362277834..5139dec085f2
linux-next for a
bit to see if any problems shake out.
[1]:
https://lore.kernel.org/linux-fsdevel/20230807-mgctime-v7-0-d1dec143a...@kernel.org/
Signed-off-by: Jeff Layton
---
Jeff Layton (10):
fs: turn inode ctime fields into a single ktime_t
fs: uninline inode_get_ctime and
inode->i_sb->s_dev),
> - MINOR(inode->i_sb->s_dev), inode->i_ino);
> + MAJOR(dev), MINOR(dev), inode->i_ino);
> } else {
> seq_printf(f, "%d :0 ", fl_pid);
> }
--
Jeff Layton
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2018-01-31 at 08:46 -0800, Linus Torvalds wrote:
> On Wed, Jan 31, 2018 at 4:29 AM, Jeff Layton wrote:
> >
> > Do you mind just taking it directly? I don't have anything else queued
> > up for this cycle.
>
> Done.
>
Thanks...and also many thanks
gt; and nobody saves it into anything but a "bool" (which has magical
> casting properties and does not lose upper bits).
>
> Linus
Do you mind just taking it directly? I don't have anything else queued
up for this cycle.
Thanks,
--
Jeff Layton
--
From: Jeff Layton
As Linus points out:
The inode_cmp_iversion{+raw}() functions are pure and utter crap.
Why?
You say that they return 0/negative/positive, but they do so in a
completely broken manner. They return that ternary value as the
sequence number difference in a
On Tue, 2018-01-30 at 17:50 +, Trond Myklebust wrote:
> On Tue, 2018-01-30 at 12:31 -0500, Jeff Layton wrote:
> > From: Jeff Layton
> >
> > As Linus points out:
> >
> > The inode_cmp_iversion{+raw}() functions are pure and utter crap.
> >
>
From: Jeff Layton
As Linus points out:
The inode_cmp_iversion{+raw}() functions are pure and utter crap.
Why?
You say that they return 0/negative/positive, but they do so in a
completely broken manner. They return that ternary value as the
sequence number difference in a
On Mon, 2018-01-29 at 13:50 -0800, Linus Torvalds wrote:
> On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote:
> >
> > This pile of patches is a rework of the inode->i_version field. We have
> > traditionally incremented that field on every inode data or metadata
&g
re problems.
Thanks!
----
Jeff Layton (21):
lustre: don't set f_version in ll_readdir
ntfs: remove i_version handling
fs: new API for handling inode->i_version
fs: don't take the i_lock in inode_inc_iversi
On Thu, 2018-01-18 at 16:45 -0500, J. Bruce Fields wrote:
> On Tue, Jan 09, 2018 at 09:10:42AM -0500, Jeff Layton wrote:
> > From: Jeff Layton
> >
> > The rationale for taking the i_lock when incrementing this value is
> > lost in antiquity. The readers of the fi
On Thu, 2018-01-18 at 16:38 -0500, J. Bruce Fields wrote:
> On Tue, Jan 09, 2018 at 09:10:41AM -0500, Jeff Layton wrote:
> > --- /dev/null
> > +++ b/include/linux/iversion.h
> > @@ -0,0 +1,236 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifnd
On Thu, 2018-01-11 at 12:23 -0800, Liu Bo wrote:
> On Tue, Jan 09, 2018 at 09:10:40AM -0500, Jeff Layton wrote:
> > From: Jeff Layton
> >
> > v5:
> > - don't corrupt refcounts stashed in i_version of ext4 xattr inodes
> > - add raw variants of inc an
From: Jeff Layton
v5:
- don't corrupt refcounts stashed in i_version of ext4 xattr inodes
- add raw variants of inc and cmp functions, and have nfs use them
v4:
- fix SB_LAZYTIME handling in generic_update_time
- add memory barriers to patch to convert i_version field to atomic64_t
v3:
-
From: Jeff Layton
Add a documentation blob that explains what the i_version field is, how
it is expected to work, and how it is currently implemented by various
filesystems.
We already have inode_inc_iversion. Add several other functions for
manipulating and accessing the i_version counter. For
From: Jeff Layton
The rationale for taking the i_lock when incrementing this value is
lost in antiquity. The readers of the field don't take it (at least
not universally), so my assumption is that it was only done here to
serialize incrementors.
If that is indeed the case, then we can dro
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/fat/dir.c | 3 ++-
fs/fat/inode.c | 9 +
fs/fat/namei_msdos.c | 7 ---
fs/fat/namei_vfat.c | 22 +++---
4 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/fs/fat/dir.c b/fs/fat/dir.c
1 - 100 of 410 matches
Mail list logo
