The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: cmm@us.ibm.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [EXT4 set 4][PATCH 5/5] i_version: noversion mount option to disable inode version updates
Date: Wed, 11 Jul 2007 11:48:38 -0400	[thread overview]
Message-ID: <20070711154838.GB19456@thunk.org> (raw)
In-Reply-To: <20070710163144.21b739f9.akpm@linux-foundation.org>

On Tue, Jul 10, 2007 at 04:31:44PM -0700, Andrew Morton wrote:
> On Sun, 01 Jul 2007 03:37:53 -0400
> Mingming Cao <cmm@us.ibm.com> wrote:
> 
> > Add a "noversion" mount option to disable inode version updates.
> 
> Why is this option being offered to our users?  To reduce disk traffic,
> like noatime?
> 
> If so, what are the implications of this?  What would the user lose?

This has been removed in the latest patch set; it's needed only for
Lustre, because they set the version field themselves.  Lustre needs
the inode version to be globally monotonically increasing, so it can
order updates between two different files, so it does this itself.
NFSv4 only uses i_version to detect changes, and so there's no need to
use a global atomic counter for i_version.  So the thinking was that
there was no point doing the global atomic counter if it was not necessary.

Since "noversion" is Lustre specific, we've dropped that from the list
of patches that we'll push, and so the inode version will only have
local per-inode significance, and not have any global ordering
properties.  

We have not actually benchmarked whether or not doing the global
ordering actually *matters* in terms of being actually noticeable.  If
it isn't noticeable, I wouldn't mind changing things so that we always
make i_version globally significant (without a mount option), and make
life a bit easier for the Lustre folks.  Or if someone other
distributed filesystem requests a globally significant i_version.  But
we can cross that bridge when we get to it....

						- Ted

      parent reply	other threads:[~2007-07-11 15:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01  7:37 [EXT4 set 4][PATCH 5/5] i_version: noversion mount option to disable inode version updates Mingming Cao
2007-07-10 23:31 ` Andrew Morton
2007-07-11 11:57   ` Andreas Dilger
2007-07-11 12:03     ` Christoph Hellwig
2007-07-11 15:48   ` Theodore Tso [this message]

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=20070711154838.GB19456@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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