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: <0c5ef1d2-235c-48c1-9a7a-5e52f3a34855@www.fastmail.com>
In-Reply-To: <0339f5f540010ba1bae74121d33c0643f26fefab.camel@kernel.org>
References: <20220819115641.14744-1-jlayton@kernel.org>
 <20220823215333.GC3144495@dread.disaster.area>
 <fc59bfa8-295e-4180-9cf0-c2296d2e8707@www.fastmail.com>
 <0339f5f540010ba1bae74121d33c0643f26fefab.camel@kernel.org>
Date:   Fri, 26 Aug 2022 04:44:23 -0400
From:   "Colin Walters" <walters@verbum.org>
To:     "Jeff Layton" <jlayton@kernel.org>,
        "Dave Chinner" <david@fromorbit.com>
Cc:     "Al Viro" <viro@zeniv.linux.org.uk>, linux-api@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
        "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

Bigger picture, I think eventually I'm going to rework stuff related to my use case to be more similar to the container stack, specifically using overlayfs; so it's quite possible by the time iversion is exposed to userspace, I won't have any strong want/need of it myself.

On Thu, Aug 25, 2022, at 3:48 PM, Jeff Layton wrote:

> IOW, should this value mean that something _did_ change in the inode or
> that something _may_ have changed in it?

In my case it's basically the same as IMA - we want to only compute the sha256 digest of files that actually changed.  Some false positives are hence OK - but that also means the usefulness of the feature degrades in proportion to that number.

A bit more detail:

I didn't deep dive into the XFS mention about internal/background iversion changes, but AIUI at a high level it sounds like those iversion changes happen mainly (only?) when the file is recently created and pending writeback, which doesn't seem like a problem in practice.  I do agree with Ingo's old quote about atime though in https://lwn.net/Articles/244829/ and this thread reminded me to use `noatime` on my main workstation (again; I'd recently changed how I provision it).