From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_inode_buf.c | 5 +++--
fs/xfs/xfs_icache.c | 4 ++--
fs/xfs/xfs_inode.c| 2 +-
fs/xfs/xfs_inode_item.c | 2 +-
fs/xfs/xfs_trans_inode.c | 2 +-
5 files changed, 8 insertions(+), 7 deletions
From: Jeff Layton <jlay...@redhat.com>
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/nfsd/nfsfh.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
From: Jeff Layton
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton
---
fs/nfsd/nfsfh.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfsfh.h b/fs/nfsd/nfsfh.h
index 43
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/security/i
From: Jeff Layton
Signed-off-by: Jeff Layton
---
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index c7e8db0ea4c0
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ocfs2/dir.c | 14 +++---
fs/ocfs2/inode.c| 2 +-
fs/ocfs2/namei.c| 2 +-
fs/ocfs2/quota_global.c | 2 +-
4 files changed, 10 insertions(+), 10 deleti
From: Jeff Layton <jlay...@redhat.com>
We only really need to update i_version if someone has queried for it
since we last incremented it. By doing that, we can avoid having to
update the inode if the times haven't changed.
If the times have changed, then we go ahead and forcibly inc
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/ocfs2/dir.c | 14 +++---
fs/ocfs2/inode.c| 2 +-
fs/ocfs2/namei.c| 2 +-
fs/ocfs2/quota_global.c | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
From: Jeff Layton
We only really need to update i_version if someone has queried for it
since we last incremented it. By doing that, we can avoid having to
update the inode if the times haven't changed.
If the times have changed, then we go ahead and forcibly increment the
counter, under
From: Jeff Layton <jlay...@redhat.com>
Since i_version is mostly treated as an opaque value, we can exploit that
fact to avoid incrementing it when no one is watching. With that change,
we can avoid incrementing the counter on writes, unless someone has
queried for it since it wa
From: Jeff Layton
Since i_version is mostly treated as an opaque value, we can exploit that
fact to avoid incrementing it when no one is watching. With that change,
we can avoid incrementing the counter on writes, unless someone has
queried for it since it was last incremented. If the a/c/mtime
From: Jeff Layton <jlay...@redhat.com>
At this point, we know that "now" and the file times may differ, and we
suspect that the i_version has been flagged to be bumped. Attempt to
bump the i_version, and only mark the inode dirty if that actually
occurred or if one of the t
From: Jeff Layton <jlay...@redhat.com>
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_trans_
From: Jeff Layton
At this point, we know that "now" and the file times may differ, and we
suspect that the i_version has been flagged to be bumped. Attempt to
bump the i_version, and only mark the inode dirty if that actually
occurred or if one of the times was updated.
Signed-of
From: Jeff Layton
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_trans_inode.c b/fs/xfs/xfs_trans_inode.c
index b41a92d18140
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ext2/dir.c | 8
fs/ext2/super.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 987647986f47..c99f14fec3f3 100644
-
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/ext2/dir.c | 8
fs/ext2/super.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 987647986f47..c99f14fec3f3 100644
--- a/fs/ext2/dir.c
+++ b/fs/ext2/dir.c
@@ -92,7 +92,7
From: Jeff Layton <jlay...@redhat.com>
For AFS, it's generally treated as an opaque value, so we use the
*_raw variants of the API here.
Note that AFS has quite a different definition for this counter. AFS
only increments it on changes to the data, not for the metadata. We'll
need to rec
From: Jeff Layton
For AFS, it's generally treated as an opaque value, so we use the
*_raw variants of the API here.
Note that AFS has quite a different definition for this counter. AFS
only increments it on changes to the data, not for the metadata. We'll
need to reconcile that somehow if we
From: Jeff Layton <jlay...@redhat.com>
v2:
- xfs should use inode_peek_iversion instead of inode_peek_iversion_raw
- rework file_update_time patch
- don't dirty inode when only S_ATIME is set and SB_LAZYTIME is enabled
- better comments and documentation
tl;dr: I think we can greatly
From: Jeff Layton
v2:
- xfs should use inode_peek_iversion instead of inode_peek_iversion_raw
- rework file_update_time patch
- don't dirty inode when only S_ATIME is set and SB_LAZYTIME is enabled
- better comments and documentation
tl;dr: I think we can greatly reduce the cost of the inode
On Thu, 2017-12-14 at 10:14 -0500, J. Bruce Fields wrote:
> On Thu, Dec 14, 2017 at 09:14:47AM -0500, Jeff Layton wrote:
> > On Wed, 2017-12-13 at 19:02 -0500, Jeff Layton wrote:
> > > On Thu, 2017-12-14 at 10:03 +1100, Dave Chinner wrote:
> > > > On Wed, Dec 13,
On Thu, 2017-12-14 at 10:14 -0500, J. Bruce Fields wrote:
> On Thu, Dec 14, 2017 at 09:14:47AM -0500, Jeff Layton wrote:
> > On Wed, 2017-12-13 at 19:02 -0500, Jeff Layton wrote:
> > > On Thu, 2017-12-14 at 10:03 +1100, Dave Chinner wrote:
> > > > On Wed, Dec 13,
On Wed, 2017-12-13 at 09:20 -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> At this point, we know that "now" and the file times may differ, and we
> suspect that the i_version has been flagged to be bumped. Attempt to
> bump the i_version
On Wed, 2017-12-13 at 09:20 -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> At this point, we know that "now" and the file times may differ, and we
> suspect that the i_version has been flagged to be bumped. Attempt to
> bump the i_version, and only mark the ino
On Wed, 2017-12-13 at 09:20 -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> We only really need to update i_version if someone has queried for it
> since we last incremented it. By doing that, we can avoid having to
> update the inode if the
On Wed, 2017-12-13 at 09:20 -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> We only really need to update i_version if someone has queried for it
> since we last incremented it. By doing that, we can avoid having to
> update the inode if the times haven't changed.
>
&
On Wed, 2017-12-13 at 19:02 -0500, Jeff Layton wrote:
> On Thu, 2017-12-14 at 10:03 +1100, Dave Chinner wrote:
> > On Wed, Dec 13, 2017 at 03:14:28PM -0500, Jeff Layton wrote:
> > > On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> > > > This is great, t
On Wed, 2017-12-13 at 19:02 -0500, Jeff Layton wrote:
> On Thu, 2017-12-14 at 10:03 +1100, Dave Chinner wrote:
> > On Wed, Dec 13, 2017 at 03:14:28PM -0500, Jeff Layton wrote:
> > > On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> > > > This is great, t
On Thu, 2017-12-14 at 13:17 +1100, Dave Chinner wrote:
> On Wed, Dec 13, 2017 at 07:10:22PM -0500, Jeff Layton wrote:
> > On Thu, 2017-12-14 at 10:25 +1100, Dave Chinner wrote:
> > > So now I've looked at the last patch .
> > >
> > > On Thu, Dec 14, 20
On Thu, 2017-12-14 at 13:17 +1100, Dave Chinner wrote:
> On Wed, Dec 13, 2017 at 07:10:22PM -0500, Jeff Layton wrote:
> > On Thu, 2017-12-14 at 10:25 +1100, Dave Chinner wrote:
> > > So now I've looked at the last patch .
> > >
> > > On Thu, Dec 14, 20
On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
> On Wed, Dec 13 2017, Jeff Layton wrote:
>
> > +/*
> > + * The change attribute (i_version) is mandated by NFSv4 and is mostly for
> > + * knfsd, but is also used for other purposes (e.g. IMA). The i_version
> >
On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
> On Wed, Dec 13 2017, Jeff Layton wrote:
>
> > +/*
> > + * The change attribute (i_version) is mandated by NFSv4 and is mostly for
> > + * knfsd, but is also used for other purposes (e.g. IMA). The i_version
> >
On Thu, 2017-12-14 at 10:25 +1100, Dave Chinner wrote:
> So now I've looked at the last patch .
>
> On Thu, Dec 14, 2017 at 09:48:37AM +1100, Dave Chinner wrote:
> > On Wed, Dec 13, 2017 at 09:20:12AM -0500, Jeff Layton wrote:
> > > From: Jeff Layton <jlay...@redh
On Thu, 2017-12-14 at 10:25 +1100, Dave Chinner wrote:
> So now I've looked at the last patch .
>
> On Thu, Dec 14, 2017 at 09:48:37AM +1100, Dave Chinner wrote:
> > On Wed, Dec 13, 2017 at 09:20:12AM -0500, Jeff Layton wrote:
> > > From: Jeff Layton
> > >
On Thu, 2017-12-14 at 10:03 +1100, Dave Chinner wrote:
> On Wed, Dec 13, 2017 at 03:14:28PM -0500, Jeff Layton wrote:
> > On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> > > This is great, thanks.
> > >
> > > On Wed, Dec 13, 2017 at
On Thu, 2017-12-14 at 10:03 +1100, Dave Chinner wrote:
> On Wed, Dec 13, 2017 at 03:14:28PM -0500, Jeff Layton wrote:
> > On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> > > This is great, thanks.
> > >
> > > On Wed, Dec 13, 2017 at
On Wed, 2017-12-13 at 15:14 -0500, Jeff Layton wrote:
> On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> > This is great, thanks.
> >
> > On Wed, Dec 13, 2017 at 09:19:58AM -0500, Jeff Layton wrote:
> > > With this, we reduce inode metadata updates acros
On Wed, 2017-12-13 at 15:14 -0500, Jeff Layton wrote:
> On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> > This is great, thanks.
> >
> > On Wed, Dec 13, 2017 at 09:19:58AM -0500, Jeff Layton wrote:
> > > With this, we reduce inode metadata updates acros
On Wed, 2017-12-13 at 09:20 -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> 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 assumptio
On Wed, 2017-12-13 at 09:20 -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 field don't take it (at least
> not universally), so my assumption is that it was
On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> This is great, thanks.
>
> On Wed, Dec 13, 2017 at 09:19:58AM -0500, Jeff Layton wrote:
> > With this, we reduce inode metadata updates across all 3 filesystems
> > down to roughly the frequency of the timestamp gran
On Wed, 2017-12-13 at 10:05 -0500, J. Bruce Fields wrote:
> This is great, thanks.
>
> On Wed, Dec 13, 2017 at 09:19:58AM -0500, Jeff Layton wrote:
> > With this, we reduce inode metadata updates across all 3 filesystems
> > down to roughly the frequency of the timestamp gran
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/fat/dir.c | 2 +-
fs/fat/inode.c | 8
fs/fat/namei_msdos.c | 6 +++---
fs/fat/namei_vfat.c | 20 ++--
4 files changed, 18 insertions(+), 18 deleti
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/fat/dir.c | 2 +-
fs/fat/inode.c | 8
fs/fat/namei_msdos.c | 6 +++---
fs/fat/namei_vfat.c | 20 ++--
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/fs/fat/dir.c b/fs/fat/dir.c
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/affs/amigaffs.c | 4 ++--
fs/affs/dir.c | 4 ++--
fs/affs/super.c| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amig
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/affs/amigaffs.c | 4 ++--
fs/affs/dir.c | 4 ++--
fs/affs/super.c| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amigaffs.c
index 0f0e6925e97d..085a93bea1e2 100644
--- a/fs/affs
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/exofs/dir.c | 8
fs/exofs/super.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..36e314083b80 100644
--
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/exofs/dir.c | 8
fs/exofs/super.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..36e314083b80 100644
--- a/fs/exofs/dir.c
+++ b/fs/exofs/dir.c
@@ -60,7
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/btrfs/delayed-inode.c | 6 --
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 3 ++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/delayed-
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/btrfs/delayed-inode.c | 6 --
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 3 ++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 5d73f79ded8b
From: Jeff Layton <jlay...@redhat.com>
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 acc
From: Jeff Layton <jlay...@redhat.com>
For AFS, it's generally treated as an opaque value, so we use the
*_raw variants of the API here.
Note that AFS has quite a different definition for this counter. AFS
only increments it on changes to the data, not for the metadata. We'll
need to rec
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
From: Jeff Layton
For AFS, it's generally treated as an opaque value, so we use the
*_raw variants of the API here.
Note that AFS has quite a different definition for this counter. AFS
only increments it on changes to the data, not for the metadata. We'll
need to reconcile that somehow if we
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ocfs2/dir.c | 14 +++---
fs/ocfs2/inode.c| 2 +-
fs/ocfs2/namei.c| 2 +-
fs/ocfs2/quota_global.c | 2 +-
4 files changed, 10 insertions(+), 10 deleti
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/ocfs2/dir.c | 14 +++---
fs/ocfs2/inode.c| 2 +-
fs/ocfs2/namei.c| 2 +-
fs/ocfs2/quota_global.c | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ext4/dir.c| 8
fs/ext4/inline.c | 6 +++---
fs/ext4/inode.c | 12
fs/ext4/ioctl.c | 2 +-
fs/ext4/namei.c | 4 ++--
fs/ext4/super.c | 2 +-
fs/ext4/x
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/ext4/dir.c| 8
fs/ext4/inline.c | 6 +++---
fs/ext4/inode.c | 12
fs/ext4/ioctl.c | 2 +-
fs/ext4/namei.c | 4 ++--
fs/ext4/super.c | 2 +-
fs/ext4/xattr.c | 4 ++--
7 files changed, 21 insertions(+), 17
From: Jeff Layton <jlay...@redhat.com>
For NFS, we just use the "raw" API since the i_version is mostly
managed by the server. The exception there is when the client
holds a write delegation, but we only need to bump it once
there anyway to handle CB_GETATTR.
Signed-off-by: J
From: Jeff Layton
For NFS, we just use the "raw" API since the i_version is mostly
managed by the server. The exception there is when the client
holds a write delegation, but we only need to bump it once
there anyway to handle CB_GETATTR.
Signed-off-by: Jeff Layton
---
fs/nfs/de
From: Jeff Layton <jlay...@redhat.com>
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/nfsd/nfsfh.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
From: Jeff Layton
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton
---
fs/nfsd/nfsfh.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfsfh.h b/fs/nfsd/nfsfh.h
index 43
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ufs/dir.c | 8
fs/ufs/inode.c | 2 +-
fs/ufs/super.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..547c4d4
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/ufs/dir.c | 8
fs/ufs/inode.c | 2 +-
fs/ufs/super.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..547c4d4c4db8 100644
--- a/fs/ufs/dir.c
+++ b/fs/ufs/dir.c
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/xfs/libxfs/xfs_inode_buf.c | 5 +++--
fs/xfs/xfs_icache.c | 4 ++--
fs/xfs/xfs_inode.c| 2 +-
fs/xfs/xfs_inode_item.c | 2 +-
fs/xfs/xfs_trans_inode.c | 2
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_inode_buf.c | 5 +++--
fs/xfs/xfs_icache.c | 4 ++--
fs/xfs/xfs_inode.c| 2 +-
fs/xfs/xfs_inode_item.c | 2 +-
fs/xfs/xfs_trans_inode.c | 2 +-
5 files changed, 8 insertions(+), 7 deletions
From: Jeff Layton <jlay...@redhat.com>
We only really need to update i_version if someone has queried for it
since we last incremented it. By doing that, we can avoid having to
update the inode if the times haven't changed.
If the times have changed, then we go ahead and forcibly inc
From: Jeff Layton
We only really need to update i_version if someone has queried for it
since we last incremented it. By doing that, we can avoid having to
update the inode if the times haven't changed.
If the times have changed, then we go ahead and forcibly increment the
counter, under
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/security/i
From: Jeff Layton
Signed-off-by: Jeff Layton
---
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index c7e8db0ea4c0
From: Jeff Layton <jlay...@redhat.com>
At this point, we know that "now" and the file times may differ, and we
suspect that the i_version has been flagged to be bumped. Attempt to
bump the i_version, and only mark the inode dirty if that actually
occurred or if one of the t
From: Jeff Layton
At this point, we know that "now" and the file times may differ, and we
suspect that the i_version has been flagged to be bumped. Attempt to
bump the i_version, and only mark the inode dirty if that actually
occurred or if one of the times was updated.
Signed-of
From: Jeff Layton <jlay...@redhat.com>
Since i_version is mostly treated as an opaque value, we can exploit that
fact to avoid incrementing it when no one is watching. With that change,
we can avoid incrementing the counter on writes, unless someone has
queried for it since it wa
From: Jeff Layton
Since i_version is mostly treated as an opaque value, we can exploit that
fact to avoid incrementing it when no one is watching. With that change,
we can avoid incrementing the counter on writes, unless someone has
queried for it since it was last incremented. If the a/c/mtime
From: Jeff Layton <jlay...@redhat.com>
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 th
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 drop
From: Jeff Layton <jlay...@redhat.com>
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_trans_
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ext2/dir.c | 8
fs/ext2/super.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 987647986f47..c99f14fec3f3 100644
-
From: Jeff Layton
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_trans_inode.c b/fs/xfs/xfs_trans_inode.c
index b41a92d18140
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/ext2/dir.c | 8
fs/ext2/super.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 987647986f47..c99f14fec3f3 100644
--- a/fs/ext2/dir.c
+++ b/fs/ext2/dir.c
@@ -92,7 +92,7
From: Jeff Layton <jlay...@redhat.com>
About a year ago, I sent a pile of patches that overhauled how the
inode->i_version field is handled in filesystems. This is a follow up
to that initial series.
tl;dr: I think we can greatly reduce the cost of the inode->i_version
counter, b
From: Jeff Layton
About a year ago, I sent a pile of patches that overhauled how the
inode->i_version field is handled in filesystems. This is a follow up
to that initial series.
tl;dr: I think we can greatly reduce the cost of the inode->i_version
counter, by exploiting the fact that we
On Thu, 2017-12-07 at 09:35 -0500, Mimi Zohar wrote:
> On Thu, 2017-12-07 at 07:01 -0500, Jeff Layton wrote:
> > On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote:
> > > On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote:
> > > > Quoting Jeff Layton (jlay.
On Thu, 2017-12-07 at 09:35 -0500, Mimi Zohar wrote:
> On Thu, 2017-12-07 at 07:01 -0500, Jeff Layton wrote:
> > On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote:
> > > On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote:
> > > > Quoting Jeff Layton (jlay.
On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote:
> On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote:
> > Quoting Jeff Layton (jlay...@kernel.org):
> > > From: Jeff Layton <jlay...@redhat.com>
> > >
> > > The init_once routine memsets the wh
On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote:
> On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote:
> > Quoting Jeff Layton (jlay...@kernel.org):
> > > From: Jeff Layton
> > >
> > > The init_once routine memsets the whole object to 0,
From: Jeff Layton <jlay...@redhat.com>
Hi Andrew,
I sent these patches to the various fs maintainers prior to the last
merge window, but they didn't get picked up. This is mainly removing
i_version/f_version handling from filesystems that don't implement it
properly, and that don't use it
From: Jeff Layton
Hi Andrew,
I sent these patches to the various fs maintainers prior to the last
merge window, but they didn't get picked up. This is mainly removing
i_version/f_version handling from filesystems that don't implement it
properly, and that don't use it anyway.
This is almost
From: Jeff Layton <jlay...@redhat.com>
NTFS keeps track of the i_version counter here, seemingly for no reason.
It does not set the SB_I_VERSION flag so it'll never be incremented on
write, and it doesn't increment it internally for metadata operations.
Signed-off-by: Jeff Layton
From: Jeff Layton
NTFS keeps track of the i_version counter here, seemingly for no reason.
It does not set the SB_I_VERSION flag so it'll never be incremented on
write, and it doesn't increment it internally for metadata operations.
Signed-off-by: Jeff Layton
---
fs/ntfs/inode.c | 9
From: Jeff Layton <jlay...@redhat.com>
f_version is only ever used by filesystem-specific code. Generic
VFS code never uses it.
Nothing in lustre ever looks at it, so just remove this.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Andreas Dilger <andreas.d
From: Jeff Layton <jlay...@redhat.com>
HPFS does not set SB_I_VERSION and does not use the i_version counter
internally.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/hpfs/dir.c | 1 -
fs/hpfs/dnode.c | 2 --
fs/hpfs/super.c | 1 -
3 files changed, 4 deletions(-)
dif
From: Jeff Layton
f_version is only ever used by filesystem-specific code. Generic
VFS code never uses it.
Nothing in lustre ever looks at it, so just remove this.
Signed-off-by: Jeff Layton
Reviewed-by: Andreas Dilger
---
drivers/staging/lustre/lustre/llite/dir.c | 3 ---
1 file changed, 3
From: Jeff Layton
HPFS does not set SB_I_VERSION and does not use the i_version counter
internally.
Signed-off-by: Jeff Layton
---
fs/hpfs/dir.c | 1 -
fs/hpfs/dnode.c | 2 --
fs/hpfs/super.c | 1 -
3 files changed, 4 deletions(-)
diff --git a/fs/hpfs/dir.c b/fs/hpfs/dir.c
index
exec.__request_module.get_fs_type.do_mount.SyS_mount.entry_SYSCALL_64_fastpath
> > > 7320 ±136% -7e+03 0
> > > latency_stats.sum.call_rwsem_down_write_failed.do_truncate.do_sys_ftruncate.SyS_ftruncate.entry_SYSCALL_64_fastpath
> > > 52297 ±124% -3e+04 26320 ± 16%
> > > latency_stats.sum.call_rwsem_down_read_failed.lookup_slow.walk_component.link_path_walk.path_parentat.filename_parentat.do_unlinkat.SyS_unlink.entry_SYSCALL_64_fastpath
> > > 64452 ± 83% -3e+04 31383 ± 30%
> > > latency_stats.sum.call_rwsem_down_write_failed.do_rmdir.SyS_rmdir.entry_SYSCALL_64_fastpath
> > >1867567 ±173% -2e+06 11702 ±100%
> > > latency_stats.sum.tty_release_struct.tty_release.__fput.fput.task_work_run.exit_to_usermode_loop.syscall_return_slowpath.entry_SYSCALL_64_fastpath
> > >
> > >
> > >
> > >
> > > Disclaimer:
> > > Results have been estimated based on internal Intel analysis and are
> > > provided
> > > for informational purposes only. Any difference in system hardware or
> > > software
> > > design or configuration may affect actual performance.
> > >
> > >
> > > Thanks,
> > > Xiaolong
--
Jeff Layton <jlay...@redhat.com>
exec.__request_module.get_fs_type.do_mount.SyS_mount.entry_SYSCALL_64_fastpath
> > > 7320 ±136% -7e+03 0
> > > latency_stats.sum.call_rwsem_down_write_failed.do_truncate.do_sys_ftruncate.SyS_ftruncate.entry_SYSCALL_64_fastpath
> > > 52297 ±124% -3e+04 26320 ± 16%
> > > latency_stats.sum.call_rwsem_down_read_failed.lookup_slow.walk_component.link_path_walk.path_parentat.filename_parentat.do_unlinkat.SyS_unlink.entry_SYSCALL_64_fastpath
> > > 64452 ± 83% -3e+04 31383 ± 30%
> > > latency_stats.sum.call_rwsem_down_write_failed.do_rmdir.SyS_rmdir.entry_SYSCALL_64_fastpath
> > >1867567 ±173% -2e+06 11702 ±100%
> > > latency_stats.sum.tty_release_struct.tty_release.__fput.fput.task_work_run.exit_to_usermode_loop.syscall_return_slowpath.entry_SYSCALL_64_fastpath
> > >
> > >
> > >
> > >
> > > Disclaimer:
> > > Results have been estimated based on internal Intel analysis and are
> > > provided
> > > for informational purposes only. Any difference in system hardware or
> > > software
> > > design or configuration may affect actual performance.
> > >
> > >
> > > Thanks,
> > > Xiaolong
--
Jeff Layton
then just have the engine stop parking RPCs and wake up
the waitq.
That should be enough to make suspend and resume work more reliably. If,
however, you're interested in making the cgroup freezer also work, then
we may need to do a bit more work to ensure that we don't end up with
frozen tasks sq
then just have the engine stop parking RPCs and wake up
the waitq.
That should be enough to make suspend and resume work more reliably. If,
however, you're interested in making the cgroup freezer also work, then
we may need to do a bit more work to ensure that we don't end up with
frozen tasks squatting on VFS locks.
--
Jeff Layton
straightforward.
I also would like to get my address changed in MAINTAINERS to clear that
hurdle.
Jeff Layton (3):
MAINTAINERS: s/jlay...@poochiereds.net/jlay...@kernel.org/
fcntl: don't leak fd reference when
801 - 900 of 4603 matches
Mail list logo
