i_version update for ext4
cover i_version update for ext4
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
Quoted 12 lines · Cordenner jean noel
I've updated what was previously the change attribute patch for ext4 initially posted by Alexandre Ratchov. The previous patch was introducing a
change_attributefield, now it uses thei_versionfield of the inode.The
i_versionfield 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.
Quoted 2 lines
The patch is divided into 3 parts, the vfs layer, the ext4 specific code and an user part to check
i_versionchanges 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.
Quoted 13 lines · Andreas Dilger
Quoted 12 lines · Cordenner jean noel
I've updated what was previously the change attribute patch for ext4 initially posted by Alexandre Ratchov. The previous patch was introducing a
change_attributefield, now it uses thei_versionfield of the inode.The
i_versionfield 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.
Quoted 7 lines
Quoted 2 lines
The patch is divided into 3 parts, the vfs layer, the ext4 specific code and an user part to check
i_versionchanges 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.
Quoted 25 lines · Cordenner jean noel
Quoted 14 lines · Andreas Dilger
Quoted 12 lines · Cordenner jean noel
I've updated what was previously the change attribute patch for ext4 initially posted by Alexandre Ratchov. The previous patch was introducing a
change_attributefield, now it uses thei_versionfield of the inode.The
i_versionfield 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.Quoted 8 lines
Quoted 2 lines
The patch is divided into 3 parts, the vfs layer, the ext4 specific code and an user part to check
i_versionchanges 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.
Quoted 6 lines
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.htmlI 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?
Quoted 4 lines
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Mingming Cao
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.
Quoted 31 lines · Mingming Cao
Quoted 30 lines · Cordenner jean noel
Quoted 14 lines · Andreas Dilger
Quoted 12 lines · Cordenner jean noel
I've updated what was previously the change attribute patch for ext4 initially posted by Alexandre Ratchov. The previous patch was introducing a
change_attributefield, now it uses thei_versionfield of the inode.The
i_versionfield 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.Quoted 8 lines
Quoted 2 lines
The patch is divided into 3 parts, the vfs layer, the ext4 specific code and an user part to check
i_versionchanges 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
Quoted 4 lines
Quoted 1 line
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
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4