Management of nfstime3::nseconds

[phdeniel]

Hi,

I had some weird messages compiling something from one of my users inside Ganesha: gmake said a file has a modification in year.... 2514. Using the unix command line 'stat' showed that stat believe the decimal part of the mtime and ctime for the files was negative (strange isn't it ?). Like this:

Access: 2012-04-02 09:41:36.000000000 +0200 Modify: 2012-03-28 17:00:17.-787086328 0200 Change: 2012-04-02 09:41:11.-787086328 0200

In src/Protocols/NFS/nfs_proto_tools.c, we are very strict on nfstime3::nseconds, which is used for atime, mtime and ctime inside 'struct fattr3', by using precise time measured by FSAL. If I dumbly set all "nseconds" filled to 0 when making NFS reply, the weird user message from gmake disappears and stat is fine too, but I think about that like kind of regression on time precision. Questions are:

• Should we be as precise with nseconds in v3 as we are in v4 ? Should we return nseconds=0 all the time and accept the regression ?
• Are we actually managing nseconds the way it should be ? I am afraid we consider microseconds like nanoseconds somewhere in FSAL code.

[phdeniel]

stat on NetApp filer shows only 5 significant numbers after the '.' . Shouldn't we do the same ?

[mmakc]

We do set time_delta as seconds only in FSINFO but most clients ignore it anyway, it would be prudent if server would only return nseconds which are less then a second to avoid issues with sign extension when copying from NFS to stat (in the ideal world tv_nsec would not have been made 64 bit long to avoid issues with 'lots of nanoseconds' - 32 bits is quite enough to encode 10^9 nseconds)

[phdeniel]

Max Matveev a écrit :

We do set time_delta as seconds only in FSINFO but most clients ignore it anyway, That's right, we use that in Ganesha (src/Protocols/NFS/nfs3_Fsinfo.c:+147):

   FSINFO_FIELD.time_delta.seconds = 1;
  FSINFO_FIELD.time_delta.nseconds = 0;

So the client actually ignore it, just as you said.

[phdeniel]

In fact, if I look at various filesystems (like LUSTRE), nseconds are simply ignored. In this case, if a change have been done within a second and can't be detected with mtime, then metadata "file version" is used (it correspond to FATTR4_CHANGE in NFSv4.x). Of course, NFSv3 will not have this feature.

[phdeniel]

In order to stay coherent with FSINFO and to avoid side effect, I believe that nseconds fields should be set to 0. I'll do that for both v3 and v4.

[phdeniel]

Fix by this commit 3f5280dc4af4bdf8562fc3c6793bbd9ec6ac5390