Posted Jan 24, 2008 5:27 UTC (Thu) by bfields (subscriber, #19510)
Parent article: A better ext4
"Another change is a VFS API change, in that it turns the i_version field of the inode
structure into an unsigned, 64-bit value on all architectures. This version number is
incremented when the file is changed, and it's stored (split into two fields) in the on-disk
inode. 64-bit version numbers are required by NFSv4, which uses them to provide the dreaded
"stale file handle" error when things change."
No, you're thinking of the generation number.
The intent is to use the i_version field as what the NFSv4 spec calls the "change attribute",
which is used by the client to revalidate cached data: the client can check that this value is
still the same as it was when it last looked at the file, saving it from having to re-read it.
Currently we're using the ctime for that purpose, but it's not actually guaranteed to change
every time the file changes (especially not on ext3, which has timestamps with only 1 second
resolution!).
Seems like a number that might be worth exporting to userspace some day too--other
applications could also benefit from a quick, reliable way to determine whether a file has
changed since the last time they looked at it.
(The generation number--the i_generation field of the inode--is what's used to ensure that NFS
filehandles stay distinct even when inode numbers are reused.)