[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220805220136.GG3600936@dread.disaster.area>
Date: Sat, 6 Aug 2022 08:01:36 +1000
From: Dave Chinner <david@...morbit.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, dhowells@...hat.com,
lczerner@...hat.com, bxue@...hat.com, ceph-devel@...r.kernel.org,
linux-nfs@...r.kernel.org, linux-afs@...ts.infradead.org,
linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-btrfs@...r.kernel.org, Jeff Layton <jlayton@...hat.com>
Subject: Re: [RFC PATCH 1/4] vfs: report change attribute in statx for
IS_I_VERSION inodes
On Fri, Aug 05, 2022 at 02:35:40PM -0400, Jeff Layton wrote:
> From: Jeff Layton <jlayton@...hat.com>
>
> Claim one of the spare fields in struct statx to hold a 64-bit change
> attribute. When statx requests this attribute, do an
> inode_query_iversion and fill the result in the field.
>
> Also update the test-statx.c program to fetch the change attribute as
> well.
>
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
> fs/stat.c | 7 +++++++
> include/linux/stat.h | 1 +
> include/uapi/linux/stat.h | 3 ++-
> samples/vfs/test-statx.c | 4 +++-
> 4 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/fs/stat.c b/fs/stat.c
> index 9ced8860e0f3..976e0a59ab23 100644
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -17,6 +17,7 @@
> #include <linux/syscalls.h>
> #include <linux/pagemap.h>
> #include <linux/compat.h>
> +#include <linux/iversion.h>
>
> #include <linux/uaccess.h>
> #include <asm/unistd.h>
> @@ -118,6 +119,11 @@ int vfs_getattr_nosec(const struct path *path, struct kstat *stat,
> stat->attributes_mask |= (STATX_ATTR_AUTOMOUNT |
> STATX_ATTR_DAX);
>
> + if ((request_mask & STATX_CHGATTR) && IS_I_VERSION(inode)) {
> + stat->result_mask |= STATX_CHGATTR;
> + stat->chgattr = inode_query_iversion(inode);
> + }
If you're going to add generic support for it, shouldn't there be a
generic test in fstests that ensures that filesystems that advertise
STATX_CHGATTR support actually behave correctly? Including across
mounts, and most importantly, that it is made properly stable by
fsync?
i.e. what good is this if different filesystems have random quirks
that mean it can't be relied on by userspace to tell it changes have
occurred?
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists