All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Cordenner jean noel <jean-noel.cordenner@bull.net>
Cc: Andreas Dilger <adilger@clusterfs.com>,
	linux-ext4@vger.kernel.org, nfsv4@linux-nfs.org
Subject: Re: [RFC] [patch 0/3] i_version update for ext4
Date: Wed, 24 Jan 2007 09:40:34 -0800	[thread overview]
Message-ID: <45B79A12.4060004@us.ibm.com> (raw)
In-Reply-To: <45B76961.7030509@bull.net>

Cordenner jean noel wrote:
> Andreas Dilger a écrit :
> 
>> On Jan 23, 2007  18:23 +0100, Cordenner jean noel wrote:
>>
>>> I've updated what was previously the change attribute patch for ext4
>>> initially posted by Alexandre Ratchov. The previous patch was
>>> introducing a change_attribute field, now it uses the i_version field of
>>> the inode.
>>>
>>> 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 moent, 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.
>>
>>
>> Have you had a chance to look at the performance impact of this change
>> (possible with oprofile)?  Always marking the inodes dirty for ext3
>> may have some noticable overhead.
>>
> 
> I did some tests using fileop with the previous version of the patch
> which was very similar. I was surprised that there was no noticable
> overhead:
>  http://www.bullopensource.org/ext4/change_attribute/index.html
> 
> I will use oprofile to check it again.

Could we just increment the counter each time the mtime is modifies(not 
the ctime)? Is that enough to serve NFSv4 need?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-23 17:23 [RFC] [patch 0/3] i_version update for ext4 Cordenner jean noel
2007-01-23 18:46 ` Andreas Dilger
2007-01-24 14:12   ` Cordenner jean noel
2007-01-24 17:40     ` Mingming Cao [this message]
2007-01-24 18:06       ` J. Bruce Fields
2007-01-24 18:12       ` Trond Myklebust

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=45B79A12.4060004@us.ibm.com \
    --to=cmm@us.ibm.com \
    --cc=adilger@clusterfs.com \
    --cc=jean-noel.cordenner@bull.net \
    --cc=linux-ext4@vger.kernel.org \
    --cc=nfsv4@linux-nfs.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 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.