From: Greg KH <gregkh@linuxfoundation.org>
To: Colin Walters <walters@verbum.org>
Cc: Dave Chinner <david@fromorbit.com>,
Jeff Layton <jlayton@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org, Jeff Layton <jlayton@redhat.com>,
David Howells <dhowells@redhat.com>,
Frank Filz <ffilzlnx@mindspring.com>
Subject: Re: [PATCH] vfs: report an inode version in statx for IS_I_VERSION inodes
Date: Sat, 27 Aug 2022 09:38:18 +0200 [thread overview]
Message-ID: <YwnJ6nieMHHFHqZg@kroah.com> (raw)
In-Reply-To: <fc59bfa8-295e-4180-9cf0-c2296d2e8707@www.fastmail.com>
On Thu, Aug 25, 2022 at 02:48:02PM -0400, Colin Walters wrote:
>
>
> On Tue, Aug 23, 2022, at 5:53 PM, Dave Chinner wrote:
> >
> > THere's no definition of what consitutes an "inode change" and this
> > exposes internal filesystem implementation details (i.e. on disk
> > format behaviour) directly to userspace. That means when the
> > internal filesystem behaviour changes, userspace applications will
> > see changes in stat->ino_version changes and potentially break them.
>
> As a userspace developer (ostree, etc. who is definitely interested in this functionality) I do agree with this concern; but a random drive by comment: would it be helpful to expose iversion (or other bits like this from the vfs) via e.g. debugfs to start? I think that'd unblock writing fstests in the short term right?
>
>
This would not work at all for "virtual" filesystems like debugfs and
sysfs which only create the data when the file is read, and there's no
way to know if the data is going to be different than the last time it
was read, sorry.
greg k-h
prev parent reply other threads:[~2022-08-27 7:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 11:56 [PATCH] vfs: report an inode version in statx for IS_I_VERSION inodes Jeff Layton
2022-08-23 10:01 ` Florian Weimer
2022-08-23 10:16 ` Jeff Layton
2022-08-23 21:53 ` Dave Chinner
2022-08-24 10:17 ` Jeff Layton
2022-08-25 18:48 ` Colin Walters
2022-08-25 19:48 ` Jeff Layton
2022-08-26 8:44 ` Colin Walters
2022-08-27 7:38 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YwnJ6nieMHHFHqZg@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=ffilzlnx@mindspring.com \
--cc=jlayton@kernel.org \
--cc=jlayton@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=walters@verbum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox