[OpenAFS-devel] Re: [OpenAFS] file timestamp difference

[Jeffrey Hutzelman]

On Wednesday, October 24, 2007 03:48:19 PM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> Jim Rees wrote:
>> I don't think that's the right fix.  The linux code should just use the
>> timespec returned by the vnodeop, which includes the data version in the
>> nsec field.  Otherwise the file could change but still have the same
>> mtime. I'm pretty sure that's what most of the other clients do.
>
> Jim:
>
> If you look at all of the Linux support.  It appears to be the case that
> the code is written with the assumption that time structures in the
> vattr and the iattr do not have to be the same.
>
> In the !AFS_LINUX26_ENV case the tv_usec field is being set to 0 in the
> iattr2vattr() transition.  What I don't know is whether or not this is
> being down because there is no tv_usec field in the iattr or whether it
> is because the value of the tv_usec field of the iattr is expected to be
> invalid.

Actually, you should read more closely.  iattr2vattr _always_ sets the 
tv_usec field to 0, regardless of the version.  The different between 
AFS_LINUX26_ENV and not is that on AFS_LINUX26_ENV, ia_[acm]time are 
structures, whereas on older platforms they are integer numbers of seconds.

What most likely happened here is that someone ported to 2.6 by replacing 
the assignment with one that worked, without considering that the right 
thing was to also copy and convert the microsecond times.  Of course, this 
matters little, because iattr2vattr is only used when we are trying to set 
attributes on an AFS file, and the fileserver doesn't store sub-second 
timestamps anyway.  Still, getting it right would be nice for when the 
fileserver and VNOPS gain support for sub-second timestamps.


For the other direction, Jim is right - the vnop code sets all three 
tv_nsec values to a number computed from the data version.  This is a fine 
thing to do, as it insures that if the directory changes, so does its mod 
time, which is important for some purposes (including NFS).  On the other 
hand, just setting them to 0 is also a reasonable thing to do, and would be 
consistent with the behavior on !AFS_LINUX26_ENV.

Note that on branches that include the NFS translator code, we need to be a 
bit more careful, as it's important that i_mtime.tv_nsec actually change 
when afs_sysnamegen changes, so that NFS clients will invalidate their DNLC 
when their sysname list changes.  Jeff's patch for 1.5.x does this 
currently, but it ignores the DV-based nsec that comes up from the VNOPS 
layer.  A version that wants to use that value would have to take both 
values into account.  It is probably safe to simply add them, or shift the 
usec left by 1000 and add sysnamegen mod 1000, or whatever.  The important 
things are that it changes when either DV or sysnamegen changes, and that 
it not go out of range.




> The question at the moment is what to do for 1.4.5.

The answer appears to have been "nothing".  That's sad.

-- Jeff