Re: [RFC] [patch 0/3] i_version update for ext4
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. - 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
Re: [RFC] [patch 0/3] i_version update for ext4
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - 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
Re: [RFC] [patch 0/3] i_version update for ext4
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. - 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
