From: Dave Chinner <david@fromorbit.com>
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,
bfields@fieldses.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, 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
Subject: Re: [PATCH v2 01/19] fs: new API for handling inode->i_version
Date: Sun, 17 Dec 2017 09:37:20 +1100 [thread overview]
Message-ID: <20171216223720.GL5858@dastard> (raw)
In-Reply-To: <20171216134656.15561-2-jlayton@kernel.org>
On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> From: Jeff Layton <jlayton@redhat.com>
>
> Add a documentation blob that explains what the i_version field is, how
> it is expected to work, and how it is currently implemented by various
> filesystems.
>
> We already have inode_inc_iversion. Add several other functions for
> manipulating and accessing the i_version counter. For now, the
> implementation is trivial and basically works the way that all of the
> open-coded i_version accesses work today.
>
> Future patches will convert existing users of i_version to use the new
> API, and then convert the backend implementation to do things more
> efficiently.
>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> include/linux/fs.h | 200 ++++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 192 insertions(+), 8 deletions(-)
Just a random sunday morning coffee musing....
I was just wondering if it would be better to split this stuff out
into it's own header file now? include/linux/fs.h is aleady a
massive header file (~3500 lines) and changes cause tree-wide
rebuilds, so maybe it would be better to split relatively isolated
functionality like this out while it's being reworked and you're
already touching every file that uses it?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-12-16 22:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-16 13:46 [PATCH v2 00/19] fs: rework and optimize i_version handling in filesystems Jeff Layton
2017-12-16 13:46 ` [PATCH v2 01/19] fs: new API for handling inode->i_version Jeff Layton
2017-12-16 22:37 ` Dave Chinner [this message]
2017-12-17 1:05 ` Jeff Layton
2017-12-16 13:46 ` [PATCH v2 02/19] fs: don't take the i_lock in inode_inc_iversion Jeff Layton
2017-12-16 13:46 ` [PATCH v2 03/19] fat: convert to new i_version API Jeff Layton
2017-12-16 13:46 ` [PATCH v2 04/19] affs: " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 05/19] afs: " Jeff Layton
[not found] ` <20171216134656.15561-6-jlayton-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-12-16 13:49 ` Jeff Layton
2017-12-16 16:18 ` Jeffrey Altman
2017-12-16 16:40 ` Jeff Layton
2017-12-16 13:46 ` [PATCH v2 06/19] btrfs: " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 07/19] exofs: switch " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 08/19] ext2: convert " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 09/19] ext4: " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 10/19] nfs: " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 11/19] nfsd: " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 12/19] ocfs2: " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 13/19] ufs: use " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 14/19] xfs: convert to " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 15/19] IMA: switch IMA over " Jeff Layton
2017-12-16 13:46 ` [PATCH v2 16/19] fs: only set S_VERSION when updating times if necessary Jeff Layton
2017-12-16 13:46 ` [PATCH v2 17/19] xfs: avoid setting XFS_ILOG_CORE if i_version doesn't need incrementing Jeff Layton
2017-12-16 13:46 ` [PATCH v2 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed Jeff Layton
2017-12-16 13:46 ` [PATCH v2 19/19] fs: handle inode->i_version more efficiently 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=20171216223720.GL5858@dastard \
--to=david@fromorbit.com \
--cc=adilger.kernel@dilger.ca \
--cc=bfields@fieldses.org \
--cc=clm@fb.com \
--cc=darrick.wong@oracle.com \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dsterba@suse.com \
--cc=jack@suse.de \
--cc=jbacik@fb.com \
--cc=jlayton@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).