linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	viro@zeniv.linux.org.uk, linux-nfs@vger.kernel.org,
	neilb@suse.de, jack@suse.de, linux-ext4@vger.kernel.org,
	tytso@mit.edu, adilger.kernel@dilger.ca,
	linux-xfs@vger.kernel.org, darrick.wong@oracle.com,
	david@fromorbit.com, linux-btrfs@vger.kernel.org, clm@fb.com,
	jbacik@fb.com, dsterba@suse.com, linux-integrity@vger.kernel.org,
	zohar@linux.vnet.ibm.com, dmitry.kasatkin@gmail.com,
	linux-afs@lists.infradead.org, dhowells@redhat.com,
	jaltman@auristor.com, krzk@kernel.org
Subject: Re: [PATCH v5 01/19] fs: new API for handling inode->i_version
Date: Thu, 18 Jan 2018 16:38:21 -0500	[thread overview]
Message-ID: <20180118213821.GA5299@fieldses.org> (raw)
In-Reply-To: <20180109141059.25929-2-jlayton@kernel.org>

On Tue, Jan 09, 2018 at 09:10:41AM -0500, Jeff Layton wrote:
> --- /dev/null
> +++ b/include/linux/iversion.h
> @@ -0,0 +1,236 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_IVERSION_H
> +#define _LINUX_IVERSION_H
> +
> +#include <linux/fs.h>
> +
> +/*
> + * The change attribute (i_version) is mandated by NFSv4 and is mostly for
> + * knfsd, but is also used for other purposes (e.g. IMA). The i_version must
> + * appear different to observers if there was a change to the inode's data or
> + * metadata since it was last queried.
> + *
> + * Observers see the i_version as a 64-bit number that never changes.

I don't understand that sentence.

> If it
> + * remains the same since it was last checked, then nothing has changed in the
> + * inode. If it's different then something has changed. Observers cannot infer
> + * anything about the nature or magnitude of the changes from the value, only
> + * that the inode has changed in some fashion.

As we've discussed before, there may be brief windows where the first
two statements aren't quite correct.  I think that would be worth a
mention if we can keep it concise.  Maybe add something like this?:

	It may be impractical for filesystems to keep i_version updates
	atomic with respect to the changes that cause them.  They
	should, however, guarantee that i_version updates are never
	visible before the changes that caused them.  Also, i_version
	updates should never be delayed longer than it takes the
	original change to reach disk.

Or maybe those details are best left to documentation on the relevant
parts of the api below (maybe inode_maybe_inc_iversion?).

I dunno if it's also worth mentioning that nfsd doesn't actually use the
raw i_version--it mixes it with ctime to prevent i_version reuse after
reboot.  Presumably that doesn't matter to IMA since it doesn't compare
i_version across reboots.

The documentation here is all very helpful, thanks.

--b.

  reply	other threads:[~2018-01-18 21:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 14:10 [PATCH v5 00/19] fs: rework and optimize i_version handling in filesystems Jeff Layton
2018-01-09 14:10 ` [PATCH v5 01/19] fs: new API for handling inode->i_version Jeff Layton
2018-01-18 21:38   ` J. Bruce Fields [this message]
2018-01-18 22:47     ` Jeff Layton
2018-01-09 14:10 ` [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion Jeff Layton
2018-01-09 15:14   ` Jan Kara
2018-01-18 21:45   ` J. Bruce Fields
2018-01-19 14:36     ` Jeff Layton
2018-01-19 14:43       ` J. Bruce Fields
2018-01-09 14:10 ` [PATCH v5 03/19] fat: convert to new i_version API Jeff Layton
2018-01-09 14:10 ` [PATCH v5 04/19] affs: " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 05/19] afs: " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 06/19] btrfs: " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 07/19] exofs: switch " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 08/19] ext2: convert " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 09/19] ext4: " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 10/19] nfs: " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 11/19] nfsd: " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 12/19] ocfs2: " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 13/19] ufs: use " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 14/19] xfs: convert to " Jeff Layton
2018-01-09 22:46   ` Dave Chinner
2018-01-09 14:10 ` [PATCH v5 15/19] IMA: switch IMA over " Jeff Layton
2018-01-09 14:10 ` [PATCH v5 16/19] fs: only set S_VERSION when updating times if necessary Jeff Layton
2018-01-09 14:10 ` [PATCH v5 17/19] xfs: avoid setting XFS_ILOG_CORE if i_version doesn't need incrementing Jeff Layton
2018-01-09 22:48   ` Dave Chinner
2018-01-09 14:10 ` [PATCH v5 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed Jeff Layton
2018-01-11 19:30   ` Liu Bo
2018-01-09 14:10 ` [PATCH v5 19/19] fs: handle inode->i_version more efficiently Jeff Layton
2018-01-09 22:55   ` Dave Chinner
2018-01-10 14:12   ` Krzysztof Kozlowski
2018-01-11 20:23 ` [PATCH v5 00/19] fs: rework and optimize i_version handling in filesystems Liu Bo
2018-01-12 11:49   ` Jeff Layton

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=20180118213821.GA5299@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=clm@fb.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=dsterba@suse.com \
    --cc=jack@suse.de \
    --cc=jaltman@auristor.com \
    --cc=jbacik@fb.com \
    --cc=jlayton@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.vnet.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).