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

Jeffrey Hutzelman jhutz@cmu.edu
Thu, 25 Oct 2007 19:50:09 -0400 (EDT)


On Thu, 25 Oct 2007, Jeffrey Altman wrote:

> My concern with the use of the sysnamegen hash as a means of fixing the
> NFS translator issue is that it prevents a distributed application that
> synchronizes on file timestamps to work on heterogeneous platforms.
>
> I would like to try and find a solution for this case as well.

Well, the sysname generation is only important for directories, since the
issue is getting NFS clients to discard DNLC entries.  So for regular
files, we can compute the nanoseconds part in the same way on all
platforms (of course, platforms will still differ in the resolution of
timestamps actually exposed to applications, but that's not our problem).

For directories, I don't think there is a solution that addresses the
sysnamegen issue and still provides the same sub-second timestamps on all
clients.  The sysname generation is necessarily unique to each AFS client,
and affecting the mtime is the _only_ way to force NFSv3 clients to
discard cached directory lookups.  There also is no way in Linux for us to
provide different attributes to NFS clients than we do to local processes.

BTW, note that the sysname generation is not a hash; it's just a counter.

I agree that we don't absolutely need to deal with the NFS issues in order
to come up with a solution that works for 1.4.x, but it would be nice if
in the future people running these distributed apps could upgrade some
clients to 1.5.x and still get consistent timestamps.  So if we can agree
now on a solution, or at least a set of constraints, it may help.

Do you know of any situations where applications will get unhappy about
the timestamps of directories not agreeing?


-- Jeff