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>
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
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 225544327c4f
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>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ocfs2/dir.c | 15 ---
fs/ocfs2/inode.c| 3 ++-
fs/ocfs2/namei.c| 3 ++-
fs/ocfs2/quota_global.c | 3 ++-
4
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/affs/amigaffs.c | 5 +++--
fs/affs/dir.c | 5 +++--
fs/affs/super.c| 3 ++-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amig
From: Jeff Layton
Signed-off-by: Jeff Layton
Reviewed-by: Jan Kara
---
fs/ocfs2/dir.c | 15 ---
fs/ocfs2/inode.c| 3 ++-
fs/ocfs2/namei.c| 3 ++-
fs/ocfs2/quota_global.c | 3 ++-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/fs/ocfs2
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/affs/amigaffs.c | 5 +++--
fs/affs/dir.c | 5 +++--
fs/affs/super.c| 3 ++-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amigaffs.c
index 0f0e6925e97d..14a6c1b90c9f 100644
--- a/fs/affs
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>
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>
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
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 <jlay...@redhat.com>
v4:
- fix SB_LAZYTIME handling in generic_update_time
- add memory barriers to patch to convert i_version field to atomic64_t
v3:
- move i_version handling functions to new header file
- document that the kernel-managed i_version implementation will
From: Jeff Layton
v4:
- fix SB_LAZYTIME handling in generic_update_time
- add memory barriers to patch to convert i_version field to atomic64_t
v3:
- move i_version handling functions to new header file
- document that the kernel-managed i_version implementation will appear to
increase over
On Wed, 2017-12-20 at 17:41 +0100, Jan Kara wrote:
> On Wed 20-12-17 09:03:06, Jeff Layton wrote:
> > On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> > > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > > > [PATCH] SQUASH: add memory barr
On Wed, 2017-12-20 at 17:41 +0100, Jan Kara wrote:
> On Wed 20-12-17 09:03:06, Jeff Layton wrote:
> > On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> > > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > > > [PATCH] SQUASH: add memory barr
On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > [PATCH] SQUASH: add memory barriers around i_version accesses
>
> Why explicit memory barriers rather than annotating the operations
> with the required sem
On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > [PATCH] SQUASH: add memory barriers around i_version accesses
>
> Why explicit memory barriers rather than annotating the operations
> with the required sem
On Tue, 2017-12-19 at 10:29 +0100, Jan Kara wrote:
> On Mon 18-12-17 12:22:20, Jeff Layton wrote:
> > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> > > On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > > > static inline bool
> > > > inode_maybe_in
On Tue, 2017-12-19 at 10:29 +0100, Jan Kara wrote:
> On Mon 18-12-17 12:22:20, Jeff Layton wrote:
> > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> > > On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > > > static inline bool
> > > > inode_maybe_in
On Mon, 2017-12-18 at 12:36 -0500, J. Bruce Fields wrote:
> On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote:
> > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> > > On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > > > static inline bool
> >
On Mon, 2017-12-18 at 12:36 -0500, J. Bruce Fields wrote:
> On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote:
> > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> > > On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > > > static inline bool
> >
On Mon, 2017-12-18 at 10:11 -0500, Jeff Layton wrote:
> 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.
On Mon, 2017-12-18 at 10:11 -0500, Jeff Layton wrote:
> 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_iversi
On Mon, 2017-12-18 at 17:07 +0100, Jan Kara wrote:
> On Mon 18-12-17 10:11:53, 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. B
On Mon, 2017-12-18 at 17:07 +0100, Jan Kara wrote:
> On Mon 18-12-17 10:11:53, 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 hav
On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > static inline bool
> > inode_maybe_inc_iversion(struct inode *inode, bool force)
> > {
> > - atomic64_t *ivp = (atomic64_t *)>i_version;
> > + u64 cur,
On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > static inline bool
> > inode_maybe_inc_iversion(struct inode *inode, bool force)
> > {
> > - atomic64_t *ivp = (atomic64_t *)>i_version;
> > + u64 cur,
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
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 <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/affs/amigaffs.c | 5 +++--
fs/affs/dir.c | 5 +++--
fs/affs/super.c| 3 ++-
3 files changed, 8 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 | 5 +++--
fs/affs/dir.c | 5 +++--
fs/affs/super.c| 3 ++-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amigaffs.c
index 0f0e6925e97d..14a6c1b90c9f 100644
--- a/fs/affs
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>
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>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/exofs/dir.c | 9 +
fs/exofs/super.c | 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..c5a53fcc43ea 100
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/exofs/dir.c | 9 +
fs/exofs/super.c | 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..c5a53fcc43ea 100644
--- a/fs/exofs/dir.c
+++ b/fs/exofs/dir.c
@@ -31,6
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 <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ext2/dir.c | 9 +
fs/ext2/super.c | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/f
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
Signed-off-by: Jeff Layton
Reviewed-by: Jan Kara
---
fs/ext2/dir.c | 9 +
fs/ext2/super.c | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 987647986f47..4111085a129f 100644
--- a/fs/ext2/dir.c
+++ b/fs
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 | 3 ++-
1 file changed, 2 insertions(+), 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 | 3 ++-
1 file changed, 2 insertions(+), 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/xfs/libxfs/xfs_inode_buf.c | 7 +--
fs/xfs/xfs_icache.c | 5 +++--
fs/xfs/xfs_inode.c| 3 ++-
fs/xfs/xfs_inode_item.c | 3 ++-
fs/xfs/xfs_trans_inode.c
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/xfs/libxfs/xfs_inode_buf.c | 7 +--
fs/xfs/xfs_icache.c | 5 +++--
fs/xfs/xfs_inode.c| 3 ++-
fs/xfs/xfs_inode_item.c | 3 ++-
fs/xfs/xfs_trans_inode.c | 4 +++-
5 files changed, 15 insertions(+), 7
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ufs/dir.c | 9 +
fs/ufs/inode.c | 3 ++-
fs/ufs/super.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/ufs/dir.c | 9 +
fs/ufs/inode.c | 3 ++-
fs/ufs/super.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..50dfce000864 100644
--- a/fs/ufs/dir.c
+++ b/fs/ufs
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
security/integrity/ima/ima_api.c | 3 ++-
security/integrity/ima/ima_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/securi
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
Signed-off-by: Jeff Layton
---
security/integrity/ima/ima_api.c | 3 ++-
security/integrity/ima/ima_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index c7e8db0ea4c0
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 225544327c4f
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>
v3:
- move i_version handling functions to new header file
- document that the kernel-managed i_version implementation will appear to
increase over time
- fix inode_cmp_iversion to handle wraparound correctly
v2:
- xfs should use inode_peek_iv
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 <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Theodore Ts'o <ty...@mit.edu>
---
fs/ext4/dir.c| 9 +
fs/ext4/inline.c | 7 ---
fs/ext4/inode.c | 13 +
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c |
From: Jeff Layton
v3:
- move i_version handling functions to new header file
- document that the kernel-managed i_version implementation will appear to
increase over time
- fix inode_cmp_iversion to handle wraparound correctly
v2:
- xfs should use inode_peek_iversion instead
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
Signed-off-by: Jeff Layton
Acked-by: Theodore Ts'o
---
fs/ext4/dir.c| 9 +
fs/ext4/inline.c | 7 ---
fs/ext4/inode.c | 13 +
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c | 5 +++--
fs/ext4/super.c | 3 ++-
fs/ext4/xattr.c | 5 +++--
7 files
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/file.c | 1 +
fs/btrfs/inode.c | 7 +--
fs/btrfs/ioctl.c | 1 +
fs/btrfs/tree-log.c | 4 +++-
fs/btrfs/xattr.c
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ocfs2/dir.c | 15 ---
fs/ocfs2/inode.c| 3 ++-
fs/ocfs2/namei.c| 3 ++-
fs/ocfs2/quota_global.c | 3 ++-
4
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
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(+),
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/file.c | 1 +
fs/btrfs/inode.c | 7 +--
fs/btrfs/ioctl.c | 1 +
fs/btrfs/tree-log.c | 4 +++-
fs/btrfs/xattr.c | 1 +
6 files changed, 16 insertions(+), 5
From: Jeff Layton
Signed-off-by: Jeff Layton
Reviewed-by: Jan Kara
---
fs/ocfs2/dir.c | 15 ---
fs/ocfs2/inode.c| 3 ++-
fs/ocfs2/namei.c| 3 ++-
fs/ocfs2/quota_global.c | 3 ++-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/fs/ocfs2
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
On Sat, 2017-12-16 at 15:17 +1100, NeilBrown wrote:
> On Wed, Dec 13 2017, Jeff Layton wrote:
>
> > On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
> > > On Wed, Dec 13 2017, Jeff Layton wrote:
> > >
> > > > +/*
> > > > + * The change at
On Sat, 2017-12-16 at 15:17 +1100, NeilBrown wrote:
> On Wed, Dec 13 2017, Jeff Layton wrote:
>
> > On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
> > > On Wed, Dec 13 2017, Jeff Layton wrote:
> > >
> > > > +/*
> > > > + * The change at
On Sat, 2017-12-16 at 15:17 +1100, NeilBrown wrote:
> On Wed, Dec 13 2017, Jeff Layton wrote:
>
> > On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
> > > On Wed, Dec 13 2017, Jeff Layton wrote:
> > >
> > > > +/*
> > > > + * The change at
On Sat, 2017-12-16 at 15:17 +1100, NeilBrown wrote:
> On Wed, Dec 13 2017, Jeff Layton wrote:
>
> > On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
> > > On Wed, Dec 13 2017, Jeff Layton wrote:
> > >
> > > > +/*
> > > > + * The change at
On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote:
> On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > Add a documentation blob that explains what the i_version field is, how
> > it is expected
On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote:
> On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> > 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 curre
On Sat, 2017-12-16 at 11:18 -0500, Jeffrey Altman wrote:
> Hi Jeff,
>
> A few thoughts on AFS usage below which might impact a future revision
> of the API. I hope they are useful.
>
> On 12/16/2017 8:49 AM, Jeff Layton wrote:
> > On Sat, 2017-12-16 at 08:46 -0500, Jeff
On Sat, 2017-12-16 at 11:18 -0500, Jeffrey Altman wrote:
> Hi Jeff,
>
> A few thoughts on AFS usage below which might impact a future revision
> of the API. I hope they are useful.
>
> On 12/16/2017 8:49 AM, Jeff Layton wrote:
> > On Sat, 2017-12-16 at 08:46 -0500, Jeff
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
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 <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>
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 <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
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>
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>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Theodore Ts'o <ty...@mit.edu>
---
fs/ext4/dir.c| 8
fs/ext4/inline.c | 6 +++---
fs/ext4/inode.c | 12
fs/ext4/ioctl.c | 2 +-
fs/ext4/namei.c
From: Jeff Layton
Signed-off-by: Jeff Layton
Acked-by: Theodore Ts'o
---
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
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>
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>
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
On Sat, 2017-12-16 at 08:46 -0500, Jeff Layton wrote:
> 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 counte
On Sat, 2017-12-16 at 08:46 -0500, Jeff Layton wrote:
> 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 o
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
701 - 800 of 4603 matches
Mail list logo
