oblems.
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_iversion
fat
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 <jlay...@redhat.com>
> >
> > The rationale for taking the i_lock when incrementing this value is
> > lost in antiquit
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-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 <jlay...@redhat.com>
> >
> > v5:
> > - don't corrupt refcounts stashed in i_version of ext4 xattr inodes
> > - add raw vari
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 and cmp
> Tony
Hi Tony,
Krzysztof Kozlowski reported this late last week, and I just pushed an
updated branch earlier this morning that should fix this. It looks like
the current linux-next HEAD has the fixed patchset now too. Let me know
if that doesn't help you.
Thanks,
--
Jeff Layton <jlay...@redhat.com>
> Tony
Hi Tony,
Krzysztof Kozlowski reported this late last week, and I just pushed an
updated branch earlier this morning that should fix this. It looks like
the current linux-next HEAD has the fixed patchset now too. Let me know
if that doesn't help you.
Thanks,
--
Jeff Layton
From: Jeff Layton <jlay...@redhat.com>
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
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:
- move
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>
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>
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 to the data in regular files
and co
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 to the data in regular files
and contents of the directories. Inode
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>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: David Sterba <dste...@suse.com>
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 4 +++-
3 files changed, 12 insertio
From: Jeff Layton
Signed-off-by: Jeff Layton
Acked-by: David Sterba
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 4 +++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed
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 | 12
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c
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 | 12
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c | 4 ++--
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>
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
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>
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.
Tested-by: Krzysz
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.
Tested-by: Krzysztof Kozlowski
Signed-of
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/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>
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
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 <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
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 <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Darrick J. Wong <darrick.w...@oracle.com>
---
fs/xfs/libxfs/xfs_inode_buf.c | 7 +--
fs/xfs/xfs_icache.c | 5 +++--
fs/xfs/xfs_inode.c| 3 ++-
fs/xf
From: Jeff Layton
Signed-off-by: Jeff Layton
Acked-by: Darrick J. Wong
---
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
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>
Acked-by: Darrick J. Wong <darrick.w...@oracle.com>
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed,
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
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton
Acked-by: Darrick J. Wong
---
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
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
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>
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 | 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/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 Mon, 2018-01-08 at 21:17 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 02:15:29PM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> > > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > > &g
On Mon, 2018-01-08 at 21:17 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 02:15:29PM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> > > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > > &g
On Mon, 2018-01-08 at 14:15 -0500, Jeff Layton wrote:
> On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
> >
> > (
On Mon, 2018-01-08 at 14:15 -0500, Jeff Layton wrote:
> On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
> >
> > (
On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
>
> (...)
>
> > > > Ok, thanks. If you're seeing hangs then that might i
On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
>
> (...)
>
> > > > Ok, thanks. If you're seeing hangs then that might i
On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 08:29:24AM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 14:21 +0100, Krzysztof Kozlowski wrote:
> > > On Mon, Jan 8, 2018 at 1:56 PM, Jeff Layton <jlay...@kernel.org> wrote:
&g
On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 08:29:24AM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 14:21 +0100, Krzysztof Kozlowski wrote:
> > > On Mon, Jan 8, 2018 at 1:56 PM, Jeff Layton wrote:
> > > > On
On Mon, 2018-01-08 at 05:30 -0800, Matthew Wilcox wrote:
> On Fri, Dec 22, 2017 at 07:05:56AM -0500, Jeff Layton wrote:
> > + cur = inode_peek_iversion_raw(inode);
> > + for (;;) {
> > + /* If flag is clear then we needn't do anything */
> > +
On Mon, 2018-01-08 at 05:30 -0800, Matthew Wilcox wrote:
> On Fri, Dec 22, 2017 at 07:05:56AM -0500, Jeff Layton wrote:
> > + cur = inode_peek_iversion_raw(inode);
> > + for (;;) {
> > + /* If flag is clear then we needn't do anything */
> > +
On Mon, 2018-01-08 at 14:21 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 8, 2018 at 1:56 PM, Jeff Layton <jlay...@kernel.org> wrote:
> > On Sun, 2018-01-07 at 13:44 +0100, Krzysztof Kozlowski wrote:
> > > On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton <jlay...@kern
On Mon, 2018-01-08 at 14:21 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 8, 2018 at 1:56 PM, Jeff Layton wrote:
> > On Sun, 2018-01-07 at 13:44 +0100, Krzysztof Kozlowski wrote:
> > > On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton wrote:
> > > > From: Jeff
On Sun, 2018-01-07 at 13:44 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton <jlay...@kernel.org> wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > Since i_version is mostly treated as an opaque value, we can exploit th
On Sun, 2018-01-07 at 13:44 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton wrote:
> > 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
On Fri, 2017-12-22 at 07:05 -0500, Jeff Layton wrote:
> 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/inod
On Fri, 2017-12-22 at 07:05 -0500, Jeff Layton wrote:
> 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 ++-
> f
On Tue, 2018-01-02 at 17:50 +0100, Jan Kara wrote:
> On Fri 22-12-17 07:05: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 Tue, 2018-01-02 at 17:50 +0100, Jan Kara wrote:
> On Fri 22-12-17 07:05: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 Tue, 2018-01-02 at 17:20 +, David Howells wrote:
> Jeff Layton <jlay...@kernel.org> wrote:
>
> > Note that AFS has quite a different definition for this counter. AFS
> > only increments it on changes to the data, not for the metadata.
>
> This also appl
On Tue, 2018-01-02 at 17:20 +, David Howells wrote:
> Jeff Layton wrote:
>
> > Note that AFS has quite a different definition for this counter. AFS
> > only increments it on changes to the data, not for the metadata.
>
> This also applies to AFS directories: crea
is that that patch will go
in via the IMA tree and not via this PR.
Cheers,
--
Jeff Layton <jlay...@kernel.org>
is that that patch will go
in via the IMA tree and not via this PR.
Cheers,
--
Jeff Layton
en if changing the application were an
> option, I suspect that - for my current customer issue - we could just
> remove the fstat() calls. I doubt they are really necessary.
> I think programmers often think of stat() (and particularly fstat()) as
> fairly cheap and so they use it whenever convenient. Only NFS violates
> this expectation.
>
> Also statx() is only a real solution if/when it gets widely used. Will
> "ls -l" default to AT_STATX_DONT_SYNC ??
>
Maybe. Eventually, I could see glibc converting normal stat/fstat/etc.
to use a statx() syscall under the hood (similar to how stat syscalls on
32-bit arches will use stat64 in most cases).
With that, we could look at any number of ways to sneak a "don't flush"
flag into the call. Maybe an environment variable that causes the stat
syscall wrapper to add it? I think there are possibilities there that
don't necessarily require recompiling applications.
> Apart from the Posix requirement (which only requires that the
> timestamps be updated, not that the data be flushed), do you know of any
> value gained from flushing data before stat()?
>
--
Jeff Layton <jlay...@kernel.org>
application were an
> option, I suspect that - for my current customer issue - we could just
> remove the fstat() calls. I doubt they are really necessary.
> I think programmers often think of stat() (and particularly fstat()) as
> fairly cheap and so they use it whenever convenient. Only NFS violates
> this expectation.
>
> Also statx() is only a real solution if/when it gets widely used. Will
> "ls -l" default to AT_STATX_DONT_SYNC ??
>
Maybe. Eventually, I could see glibc converting normal stat/fstat/etc.
to use a statx() syscall under the hood (similar to how stat syscalls on
32-bit arches will use stat64 in most cases).
With that, we could look at any number of ways to sneak a "don't flush"
flag into the call. Maybe an environment variable that causes the stat
syscall wrapper to add it? I think there are possibilities there that
don't necessarily require recompiling applications.
> Apart from the Posix requirement (which only requires that the
> timestamps be updated, not that the data be flushed), do you know of any
> value gained from flushing data before stat()?
>
--
Jeff Layton
On Sat, 2017-12-23 at 10:14 +1100, NeilBrown wrote:
> On Fri, Dec 22 2017, 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
On Sat, 2017-12-23 at 10:14 +1100, NeilBrown wrote:
> On Fri, Dec 22 2017, 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 implemen
On Fri, 2017-12-22 at 08:43 -0600, Steve Magnani wrote:
> Jan,
>
> Re: [PATCH v4 00/19] fs: rework and optimize i_version handling in filesystems
>
> On 12/22/2017 06:05 AM, Jeff Layton wrote:
>
> > The inode->i_version field is supposed to be a value that changes
>
On Fri, 2017-12-22 at 08:43 -0600, Steve Magnani wrote:
> Jan,
>
> Re: [PATCH v4 00/19] fs: rework and optimize i_version handling in filesystems
>
> On 12/22/2017 06:05 AM, Jeff Layton wrote:
>
> > The inode->i_version field is supposed to be a value that changes
>
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/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
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/btrfs/delayed-inode.c | 7 +--
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 4 +++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/delayed-
From: Jeff Layton
Signed-off-by: Jeff Layton
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 4 +++-
3 files changed, 12 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>
---
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>
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 <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 | 12
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c
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
Signed-off-by: Jeff Layton
Acked-by: Theodore Ts'o
---
fs/ext4/dir.c| 9 +
fs/ext4/inline.c | 7 ---
fs/ext4/inode.c | 12
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c | 4 ++--
fs/ext4/super.c | 3 ++-
fs/ext4/xattr.c | 5 +++--
7 files
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 | 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>
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>
---
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
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 <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
601 - 700 of 4603 matches
Mail list logo
