[RFC] [patch 0/3] i_version update for ext4

[RFC] [patch 0/3] i_version update for ext4

[Cordenner jean noel]

Hello,

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.


Any comments are welcome.

regards,
Jean noel

Re: [RFC] [patch 0/3] i_version update for ext4

[Andreas Dilger]

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.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [RFC] [patch 0/3] i_version update for ext4

[Cordenner jean noel]

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.

Re: [RFC] [patch 0/3] i_version update for ext4

[Mingming Cao]

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

Re: [RFC] [patch 0/3] i_version update for ext4

[J. Bruce Fields]

On Wed, Jan 24, 2007 at 09:40:34AM -0800, Mingming Cao wrote:
> Could we just increment the counter each time the mtime is modifies(not 
> the ctime)? Is that enough to serve NFSv4 need?

No, the NFSv4 change attribute is also supposed to change on metadata
updates.

--b.

Re: [RFC] [patch 0/3] i_version update for ext4

[Trond Myklebust]

On Wed, 2007-01-24 at 09:40 -0800, Mingming Cao wrote:
> 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?

No. That would not conform to RFC3530:

5.5.  Mandatory Attributes - Definitions

   Name              #    DataType     Access   Description
   ___________________________________________________________________

.....

   change            3    uint64       READ     A value created by the
                                                server that the client
                                                can use to determine
                                                if file data,
                                                directory contents or
                                                attributes of the
                                                object have been
                                                modified.  The server
                                                may return the
                                                object's time_metadata
                                                attribute for this
                                                attribute's value but
                                                only if the filesystem
                                                object can not be
                                                updated more
                                                frequently than the
                                                resolution of
                                                time_metadata.

so the change attribute needs to change on both data and metadata
updates.

Cheers,
  Trond

_______________________________________________
NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4