Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: ibe7c40e9:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a
Mime-Version: 1.0
Message-Id: <fc59bfa8-295e-4180-9cf0-c2296d2e8707@www.fastmail.com>
In-Reply-To: <20220823215333.GC3144495@dread.disaster.area>
References: <20220819115641.14744-1-jlayton@kernel.org>
 <20220823215333.GC3144495@dread.disaster.area>
Date:   Thu, 25 Aug 2022 14:48:02 -0400
From:   "Colin Walters" <walters@verbum.org>
To:     "Dave Chinner" <david@fromorbit.com>,
        "Jeff Layton" <jlayton@kernel.org>
Cc:     "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
Content-Type: text/plain
Precedence: bulk


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?