All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cordenner jean noel <jean-noel.cordenner@bull.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: i_version_1_vfs_layer
Date: Fri, 16 Feb 2007 17:00:15 +0100	[thread overview]
Message-ID: <45D5D50F.5090100@bull.net> (raw)
In-Reply-To: <20070215002656.a163dee9.akpm@linux-foundation.org>

Andrew Morton a écrit :
> This:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/2.6.20-ext4-1/broken-out/i_version_1_vfs_layer
> 
> significantly deoptimises file_update_time() for major filesystems (eg, ext3).
> 
> The changelog offers no reason for this alteration.  In fact the changelog
> basically says nothing at all and needs a lot of work.
> 
> What is this patch doing and why does it need to make that change?
> 

Actually, this set of patches are still in progress. I recently profile 
them. It shows that the CPU usage is really huge, so it has to be improved.

The i_version field is a counter that is set on every inode creation and
that is incremented every time the inode data is modified (similarly to
the "ctime" time-stamp).
The aim is to fulfill NFSv4 requirements for rfc3530.
For the moment, the counter is only a 32bit value but it is planned to 
be 64bit as required.

The patch is divided into 3 parts, the vfs layer, the ext4 specific code
and an user part to check i_version changes via stat.

(cf http://permalink.gmane.org/gmane.comp.file-systems.ext4/923)

      reply	other threads:[~2007-02-16 16:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-15  8:26 i_version_1_vfs_layer Andrew Morton
2007-02-16 16:00 ` Cordenner jean noel [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=45D5D50F.5090100@bull.net \
    --to=jean-noel.cordenner@bull.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-ext4@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.