On Jul 11, 2007 16:04 -0400, J. Bruce Fields wrote: > A 32-bit i_version could in theory wrap pretty quickly, couldn't it? > That's not a problem in itself--the problem would only arise if two > subsequent client queries of the change attribute happened a multiple of > 2^32 i_version increments apart. > > This is more likely than the previous scenario, but still very unlikely. > I would have guessed that even in situations with a very high rate of > updates and a low rate of client revalidations, the chance of two > revalidations happening exactly 2^32 updates apart would still be no > more than 1 in 2^32. (Could odd characteristics of the workloads (like > updates that tend to happen in power-of-2 groups?) make it any more > likely?) > > I'd be happier if ext4 at least allowed the possibility of 64 bits in > the future. And there's always the chance someone would find a use for > an i_version that was nondecreasing, even if nfs didn't care. This would indeed be the case for ext3 filesystems updated to ext4. They will only be able to store the low 32 bits of the version, which is itself normally enough for NFSv4 because it only uses the inequality check. Having the full 64 bits available eliminates the risk of collisions, and given that the spec mandates a 64-bit version I'm sure someone will take full advantage of it in NFS at some point. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
