On Wed, Dec 13, 2006 at 06:24:28PM -0700, Andreas Dilger wrote: > On Sep 13, 2006 14:11 -0400, Trond Myklebust wrote: > > I would really have preferred a full-blown 64-bit counter as per > > RFC3530, but I suppose we could always combine this change attribute > > with the high word from ctime in order to make up the NFSv4 change > > attribute. That should keep us safe until someone develops a ramdisk > > with < 1 nsecond access time. > > Trond, can you please elaborate on the need for a 64-bit version counter > for NFSv4? I'm not Trond, but.... > What kind of requirements does NFSv4 place on the version? Monotonic is > probably a good bet. The only requirement is that it be unique (assuming a file is never modified 2^64 times). Clients can't compare them except for equality. > Does it need to be global for the filesystem Nope. > or is a per-inode version sufficient? Yes. > What functionality of NFSv4 needs the version? Clients use it to revalidate their caches. --b. - 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
