On Dec 14, 2006 11:03 -0500, Theodore Tso wrote: > There was discussion on yesterday's call about whether or not 32-bit > was enough for NFSv4, or whether it also requried 64-bits of change > notification in the RFC's. So one of the questions is whether this is > something that would justify requiring 64-bits --- and if so, maybe we > need to require that big inodes be used and store the entire 64-bit > value beyond 128 bytes. This would mean that NFSv4 cache management > couldn't be fully implemented without big inodes, or we'd have to make > do by using the inode ctime as a partial substitute. Per Trond and Bruce Field's reply to my email it seems that NFSv4 only needs the version to compare for inequality. If the change numbers are sequential for a given inode it can OPTIONALLY extract additional information about the server (i.e. it still has an up-to-date cache because it was the only one that did an update on a given file). So, I think for basic NFSv4 setups that 2^32 is sufficient (per Bull's original patch) but 2^64 is desirable to avoid collisions and allow the "sequential updates" logic to work properly for long-lived files. So, I think a 32-bit field in the small inode, and an additional 32-bit field in the large inode would be perfect. It allows this functionality to work with existing ext3 filesystems, if not quite optimally. In addition, for Lustre, could we get a 64-bit field in the superblock which contains the fs-wide version number. I'm proposing that, per the original Bull patch, l_i_reserved1 be changed to be i_version for linux, and we add i_version_hi after cr_time_extra in the large inode. The disk i_version would be stored in the vfs_inode i_version (which is already used for this same purpose). It would be good for NFSv4 if the i_version field could be expanded to 64 bits to avoid the need for it to have fs-specific operations, but failing that we can put the high word into ext4_inode_info and NFS can access it via export_operations I think. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
