linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	xfs@oss.sgi.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH-v2 0/5] add support for a lazytime mount option
Date: Mon, 24 Nov 2014 19:32:15 -0500	[thread overview]
Message-ID: <20141125003215.GD31339@thunk.org> (raw)
In-Reply-To: <20141124221145.GB24003@fieldses.org>

On Mon, Nov 24, 2014 at 05:11:45PM -0500, J. Bruce Fields wrote:
> On Mon, Nov 24, 2014 at 06:57:27AM -0500, Theodore Ts'o wrote:
> > If we want to be paranoid, we handle i_version updates non-lazily; I
> > can see arguments in favor of that.
> > 
> > Ext4 only enables MS_I_VERSION if the user asks for it explicitly, so
> > it wouldn't cause me any problems.  However, xfs and btrfs enables it
> > by default, so that means xfs and btrfs wouldn't see the benefits of
> > lazytime (if you're going to have to push I_VERSION to disk, you might
> > as well update the [acm]time while you're at it).  I've always thought
> > that we *should* do is to only enable it if nfsv4 is serving the file
> > system, and not otherwise, though, which would also give us
> > consistency across all the file systems.
> 
> I guess you need to worry about the case where you shutdown nfsd, modify
> a file, then restart nfsd--you don't want a client to miss the
> modification in that case.

Hmmm, is there a way we can determine whether the file system is being
exported via nfsv4 is running, without using MS_I_VERSION?  Maybe a
new flag?  We could just disable lazytime if nfsd is running but
otherwise always increment i_version if lazytime is enabled.  My main
concern with i_version updates was not the in-memry update of
i_version, but rather the unnecessary extra metadata write "tax" that
would be inflicted on all users, including the many that aren't
serving files via NFSv4.

That way, if you shutdown the nfsv4 server, i_version would still be
updated, but we wouldn't be forcing the writes to disk, but then when
nfs v4 server is updated again, the i_version tax would be paid again.

       	      	 	 	    	      - Ted

      reply	other threads:[~2014-11-25  0:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-22 16:54 [PATCH-v2 0/5] add support for a lazytime mount option Theodore Ts'o
2014-11-22 16:54 ` [PATCH-v2 1/5] fs: split update_time() into update_time() and write_time() Theodore Ts'o
2014-11-22 16:54 ` [PATCH-v2 2/5] vfs: add support for a lazytime mount option Theodore Ts'o
2014-11-22 16:54 ` [PATCH-v2 3/5] vfs: don't let the dirty time inodes get more than a day stale Theodore Ts'o
2014-11-24 12:27   ` Rasmus Villemoes
2014-11-24 17:10     ` Theodore Ts'o
2014-11-22 16:54 ` [PATCH-v2 4/5] vfs: add lazytime tracepoints for better debugging Theodore Ts'o
2014-11-22 16:54 ` [PATCH-v2 5/5] ext4: add support for a lazytime mount option Theodore Ts'o
2014-11-24  9:07 ` [PATCH-v2 0/5] " Christoph Hellwig
2014-11-24 11:57   ` Theodore Ts'o
2014-11-24 22:11     ` J. Bruce Fields
2014-11-25  0:32       ` Theodore Ts'o [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=20141125003215.GD31339@thunk.org \
    --to=tytso@mit.edu \
    --cc=bfields@fieldses.org \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xfs@oss.sgi.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).