linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jan Kara <jack@suse.cz>
Cc: Andreas Dilger <adilger@dilger.ca>,
	"Myklebust, Trond" <Trond.Myklebust@netapp.com>,
	Theodore Ts'o <tytso@mit.edu>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] ext4: turn on i_version updates by default
Date: Tue, 15 May 2012 08:35:50 -0400	[thread overview]
Message-ID: <20120515123550.GA7053@fieldses.org> (raw)
In-Reply-To: <20120515103021.GD22359@quack.suse.cz>

On Tue, May 15, 2012 at 12:30:21PM +0200, Jan Kara wrote:
> On Mon 14-05-12 19:54:32, J. Bruce Fields wrote:
> > On Mon, May 14, 2012 at 05:33:04PM -0600, Andreas Dilger wrote:
> > > I said as much in another reply - that once i_version is used on
> > > a filesystem, it should be made "sticky" (i.e. permanently enabled
> > > for that filesystem).  However, until that time it shouldn't be
> > > enabled just because it might one day be used.
> > > 
> > > Even better than just blindly bumping the i_version on every change,
> > > it would be better to have users of i_version (i.e. knfsd) flag the
> > > inode with "needs i_version update" then read the version.  When the
> > > filesystem/VFS bumps i_version the next time it can clear this flag
> > > and not update i_version again until after the next time i_version
> > > is actually used.
> > 
> > I really don't want to do anything more complicated than necessary.
> > 
> > What would be the worst-case test for the extra inode dirtying, so we
> > can see what the numbers actually are?
>   Something like:
> 
>   int fd, i;
>   struct timeval tv[2];
> 
>   fd = open("file", O_CREAT | O_RDWR, 0644);
>   if (fd < 0)
>     return 1;
>   for (i = 0; i < 1000000; i++) {
>     gettimeofday(tv);
>     tv[1] = tv[0];
>     if (futimes(fd, tv) < 0)
>       return 1;
>   }
>   return 0;
> 
>   And see how long does it take with and without i_version?

The complaint I hear from Andreas is that we'll cause file_update_time()
to call mark_inode_dirty() more often.

I don't believe futimes() calls file_update_time().

So maybe replace that futimes() by a one-byte write?

--b.

  reply	other threads:[~2012-05-15 12:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14 14:06 [PATCH] ext4: turn on i_version updates by default J. Bruce Fields
     [not found] ` <20120514140618.GA29902-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-05-14 15:02   ` Andreas Dilger
     [not found]     ` <9124E59E-2479-4C32-A528-3237B48DEC01-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>
2012-05-14 15:23       ` J. Bruce Fields
     [not found]         ` <20120514152334.GB29902-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-05-14 17:27           ` Andreas Dilger
     [not found]             ` <14B38D68-FAE4-444A-BCD9-7EBF7E1BBFE1-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>
2012-05-14 17:58               ` Ted Ts'o
     [not found]                 ` <20120514175822.GC1439-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2012-05-14 18:33                   ` Josef Bacik
     [not found]                     ` <20120514183316.GA1894-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2012-05-14 18:48                       ` Jeff Layton
     [not found]                         ` <20120514144802.679551fa-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2012-05-14 18:51                           ` Josef Bacik
2012-05-14 18:54                       ` J. Bruce Fields
2012-05-14 19:05                         ` Josef Bacik
     [not found]                           ` <20120514190500.GC1894-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2012-05-14 21:27                             ` Andreas Dilger
2012-05-15 13:28                               ` Josef Bacik
2012-05-15 17:59                                 ` Marco Stornelli
2012-05-15 19:18                                   ` J. Bruce Fields
2012-05-15 17:33             ` J. Bruce Fields
2012-05-15 18:50               ` djwong
2012-05-14 23:08     ` Myklebust, Trond
     [not found]       ` <1337036918.2522.32.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
2012-05-14 23:33         ` Andreas Dilger
2012-05-14 23:54           ` J. Bruce Fields
     [not found]             ` <20120514235432.GA3199-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-05-15 10:30               ` Jan Kara
2012-05-15 12:35                 ` J. Bruce Fields [this message]
2012-05-15 14:43                   ` Jan Kara
2012-05-15  0:13           ` Myklebust, Trond

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=20120515123550.GA7053@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=adilger@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).