[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220908182252.GA18939@fieldses.org>
Date: Thu, 8 Sep 2022 14:22:52 -0400
From: bfields@...ldses.org (J. Bruce Fields)
To: Jeff Layton <jlayton@...nel.org>
Cc: Theodore Ts'o <tytso@....edu>, Jan Kara <jack@...e.cz>,
NeilBrown <neilb@...e.de>, adilger.kernel@...ger.ca,
djwong@...nel.org, david@...morbit.com, trondmy@...merspace.com,
viro@...iv.linux.org.uk, zohar@...ux.ibm.com, xiubli@...hat.com,
chuck.lever@...cle.com, lczerner@...hat.com, brauner@...nel.org,
fweimer@...hat.com, linux-man@...r.kernel.org,
linux-api@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
ceph-devel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-nfs@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [man-pages RFC PATCH v4] statx, inode: document the new
STATX_INO_VERSION field
On Thu, Sep 08, 2022 at 01:40:11PM -0400, Jeff Layton wrote:
> Yeah, ok. That does make some sense. So we would mix this into the
> i_version instead of the ctime when it was available. Preferably, we'd
> mix that in when we store the i_version rather than adding it afterward.
>
> Ted, how would we access this? Maybe we could just add a new (generic)
> super_block field for this that ext4 (and other filesystems) could
> populate at mount time?
Couldn't the filesystem just return an ino_version that already includes
it?
--b.
Powered by blists - more mailing lists