From: Jeff Layton <jlayton@kernel.org>
To: Steve Magnani <steve.magnani@digidescorp.com>, Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: (Lack of) i_version handling in udf
Date: Fri, 22 Dec 2017 10:54:19 -0500 [thread overview]
Message-ID: <1513958059.3426.12.camel@kernel.org> (raw)
In-Reply-To: <19f848dd-aa94-70bc-73b2-4c1d8b352636@digidescorp.com>
On Fri, 2017-12-22 at 08:43 -0600, Steve Magnani wrote:
> Jan,
>
> Re: [PATCH v4 00/19] fs: rework and optimize i_version handling in filesystems
>
> On 12/22/2017 06:05 AM, Jeff Layton wrote:
>
> > The inode->i_version field is supposed to be a value that changes
> > whenever there is any data or metadata change to the inode. Some
> > filesystems use it internally to detect directory changes during
> > readdir. knfsd will use it if the filesystem has MS_I_VERSION set. IMA
> > will also use it to optimize away some remeasurement if it's available.
> > NFS and AFS just use it to store an opaque change attribute from the
> > server.
> >
> > Only btrfs, ext4, and xfs increment it for data changes. Because of
> > this, these filesystems must log the inode to disk whenever the
> > i_version counter changes. That has a non-zero performance impact,
> > especially on write-heavy workloads, because we end up dirtying the
> > inode metadata on every write, not just when the times change.
> >
> > It turns out though that none of these users of i_version require that
> > it change on every change to the file. The only real requirement is that
> > it be different if something changed since the last time we queried for
> > it.
> >
> > If we keep track of when something queries the value, we can avoid
> > bumping the counter and an on-disk update when nothing else has changed
> > if no one has queried it since it was last incremented.
>
> This happened to cross my radar, which made me think...is it a problem
> that the UDF driver does not have any references to i_version at all?
> I suppose R/W UDF is a small subset of the normal use cases, but the driver
> does try to support it.
>
I don't think it's really a problem. Mostly we need this for filesystems
that are exported by knfsd to deal with files that change frequently. If
it's not available we just fall back to using the ctime.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2017-12-22 15:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 12:05 [PATCH v4 00/19] fs: rework and optimize i_version handling in filesystems Jeff Layton
2017-12-22 12:05 ` [PATCH v4 01/19] fs: new API for handling inode->i_version Jeff Layton
2017-12-22 23:14 ` NeilBrown
2017-12-22 23:54 ` Jeff Layton
2018-01-02 17:01 ` Jan Kara
2017-12-25 14:50 ` Jeff Layton
2017-12-22 12:05 ` [PATCH v4 02/19] fs: don't take the i_lock in inode_inc_iversion Jeff Layton
2017-12-22 12:05 ` [PATCH v4 03/19] fat: convert to new i_version API Jeff Layton
2017-12-22 12:05 ` [PATCH v4 04/19] affs: " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 05/19] afs: " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 06/19] btrfs: " Jeff Layton
2018-01-08 17:59 ` David Sterba
2017-12-22 12:05 ` [PATCH v4 07/19] exofs: switch " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 08/19] ext2: convert " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 09/19] ext4: " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 10/19] nfs: " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 11/19] nfsd: " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 12/19] ocfs2: " Jeff Layton
2018-01-04 13:34 ` Jeff Layton
2017-12-22 12:05 ` [PATCH v4 13/19] ufs: use " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 14/19] xfs: convert to " Jeff Layton
2017-12-23 0:05 ` Darrick J. Wong
2017-12-22 12:05 ` [PATCH v4 15/19] IMA: switch IMA over " Jeff Layton
2017-12-22 12:05 ` [PATCH v4 16/19] fs: only set S_VERSION when updating times if necessary Jeff Layton
2018-01-02 16:50 ` Jan Kara
2018-01-02 19:03 ` Jeff Layton
2017-12-22 12:05 ` [PATCH v4 17/19] xfs: avoid setting XFS_ILOG_CORE if i_version doesn't need incrementing Jeff Layton
2017-12-23 0:07 ` Darrick J. Wong
2017-12-22 12:05 ` [PATCH v4 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed Jeff Layton
2018-01-08 17:59 ` David Sterba
2017-12-22 12:05 ` [PATCH v4 19/19] fs: handle inode->i_version more efficiently Jeff Layton
2018-01-02 17:00 ` Jan Kara
2018-01-07 12:44 ` Krzysztof Kozlowski
2018-01-08 12:56 ` Jeff Layton
2018-01-08 13:21 ` Krzysztof Kozlowski
2018-01-08 13:29 ` Jeff Layton
2018-01-08 17:29 ` Krzysztof Kozlowski
2018-01-08 18:00 ` Jeff Layton
2018-01-08 18:33 ` Krzysztof Kozlowski
2018-01-08 19:15 ` Jeff Layton
2018-01-08 20:05 ` Jeff Layton
2018-01-08 20:17 ` Krzysztof Kozlowski
2018-01-08 21:39 ` Jeff Layton
2018-01-09 9:27 ` Krzysztof Kozlowski
2018-01-08 13:30 ` Matthew Wilcox
2018-01-08 13:46 ` Jeff Layton
2017-12-22 14:43 ` (Lack of) i_version handling in udf Steve Magnani
2017-12-22 15:54 ` Jeff Layton [this message]
2018-01-02 17:20 ` [PATCH v4 05/19] afs: convert to new i_version API David Howells
2018-01-02 18:57 ` Jeff Layton
2018-01-03 16:28 ` David Howells
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=1513958059.3426.12.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=steve.magnani@digidescorp.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).