NFS TimeStamp - Year not time - HPC?

[Trace3TimAbbott]

I have an HPC environment and I am running GX10.0.03. I noticed that if I list the contents of a directory the time stamp shows the year the file was created when it should show the hour and minute. This seems to only happen if I list the contents the same minute it is being created. If I wait 30 seconds or so and run it again I can see the time stamp correctly. Is this a NFS "feature" or is it caused by the GX code since I am running stripped aggregates and stripped volumes.

[espcnetapp]

Tim:

Hello!  We have this exact same issue right now and we are trying to figure out a fix as well.  I opened up a ticket with NetApp and the engieer we were working with indicated that the server, not the filer, was responsible for putting the time stamp on the file.  While we are not sure that is 100% correct, we have continued to look into the issue and have been unable to isolate the skew in time.  We have run through all our NTP settings on the servers and the filer as well as looking at another filer (FAS2050 - ONTAP 7.6.2.1) we have in our environment and ironically, the FAS2050 (ONTAP 7.2.6.1) does not have the same issue as our FAS3020(ONTAP 7.2.6.1).  Here is what we see on our FAS3020:

<we create the file>

[root@sanadminrh]:[3.00.15]:[14:08:57]:[data]:[2511]#: touch stuff

<we list out the contents and see the year only...>

[root@sanadminrh]:[3.00.15]:[14:09:00]:[data]:[2512]#: ll          
total 3737256                                                      
drwxr-xr-x  4 root     root           4096 Mar 27 09:20 BACKUPS    
-rw-r--r--  1 root     root              0 May 29 10:40 file       
drwxr-xr-x  5 root     root           4096 Apr 30 12:54 SCRIPTS    
-rw-r--r--  1 root     root              0 May 29  2009 stuff      
drwxrwxrwx  4 sanadmin sanadmin       4096 Apr 14 18:36 UPGRADES   
-rw-r--r--  1 root     root     3819427840 Apr 30 13:00 UPGRADES.tar

<25 seconds later no timestamp>           
[root@sanadminrh]:[3.00.15]:[14:09:24]:[data]:[2513]#: ll          
total 3737256
drwxr-xr-x  4 root     root           4096 Mar 27 09:20 BACKUPS
-rw-r--r--  1 root     root              0 May 29 10:40 file
drwxr-xr-x  5 root     root           4096 Apr 30 12:54 SCRIPTS
-rw-r--r--  1 root     root              0 May 29  2009 stuff
drwxrwxrwx  4 sanadmin sanadmin       4096 Apr 14 18:36 UPGRADES
-rw-r--r--  1 root     root     3819427840 Apr 30 13:00 UPGRADES.tar

<47 seconds still no timestamp...>
[root@sanadminrh]:[3.00.15]:[14:09:47]:[data]:[2513]#: ll
total 3737256
drwxr-xr-x  4 root     root           4096 Mar 27 09:20 BACKUPS
-rw-r--r--  1 root     root              0 May 29 10:40 file
drwxr-xr-x  5 root     root           4096 Apr 30 12:54 SCRIPTS
-rw-r--r--  1 root     root              0 May 29  2009 stuff
drwxrwxrwx  4 sanadmin sanadmin       4096 Apr 14 18:36 UPGRADES
-rw-r--r--  1 root     root     3819427840 Apr 30 13:00 UPGRADES.tar

[root@sanadminrh]:[3.00.15]:[14:09:58]:[data]:[2513]#: ll
total 3737256
drwxr-xr-x  4 root     root           4096 Mar 27 09:20 BACKUPS
-rw-r--r--  1 root     root              0 May 29 10:40 file
drwxr-xr-x  5 root     root           4096 Apr 30 12:54 SCRIPTS
-rw-r--r--  1 root     root              0 May 29  2009 stuff
drwxrwxrwx  4 sanadmin sanadmin       4096 Apr 14 18:36 UPGRADES
-rw-r--r--  1 root     root     3819427840 Apr 30 13:00 UPGRADES.tar

[root@sanadminrh]:[3.00.15]:[14:10:02]:[data]:[2513]#: ll
total 3737256
drwxr-xr-x  4 root     root           4096 Mar 27 09:20 BACKUPS
-rw-r--r--  1 root     root              0 May 29 10:40 file
drwxr-xr-x  5 root     root           4096 Apr 30 12:54 SCRIPTS
-rw-r--r--  1 root     root              0 May 29 14:10 stuff
drwxrwxrwx  4 sanadmin sanadmin       4096 Apr 14 18:36 UPGRADES
-rw-r--r--  1 root     root     3819427840 Apr 30 13:00 UPGRADES.tar

<finally a timestamp...but 1 minute AFTER the file was created.

We found this on the NetApp site, but that does not explain why we have all of the LINUX servers with our FAS2050 that are NOT having the issue...we have all the servers with the timestamp issue on the FAS3020...let us know what you found...thanks!!

*Solution ID*: kb29382 *Last updated*: 24 SEP 2008 A Linux host displays the date in the time stamp of files, but the time is omitted *Symptoms* Linux clients display the date in the time stamp after issuing the *ls** *command, but the time is omitted. When the command* ls -latr* is issued on the Linux client, the files appear in the correct order.  However, files that have been touched by the client list only the date, while files that have not been read or written are displayed correctly with both date and time information. A Linux host displays the date in the time stamp of files, but the time is omitted. *Cause of this problem* Time is out of sync. *Solution*    1. Ensure that the filer and the client's time and time zone are in       sync.    2. Issue a date command to verify the correct date, time and time zone.       *Note:*       Verify that the proper time zone rules are in effect for all       systems (ie. EDT versus EST).    3. Ensure that the proper time zone files are in */etc/**zoneinfo*       folder.    4. Issue the* timezone* command with the proper time zone to correct       any disparity.    5. Correct time skew issues with the date command. *Related link:* Updating timezone information on NetApp Appliances in the United States <https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb20094> *Environment* NetApp filer Data ONTAP GX Data ONTAP 7G and earlier

[aborzenkov]

NFS protocol provides for both server-based and client-based time stamps. As far as I can tell, Linux defaults to server-side timestamps without any way to change it (it could depend on kernel version as well).

[espcnetapp]

Andrey/Tim:

I hope that you have found the answers to your questions and if not, we were able to figure out the issue...you can see the solution at:

http://www.unixunderground.com/blog

Thank you for your reply!

Cheers,

Travis

[haopengl]

I think the correct link should be

http://www.unixunderground.com/blog/?p=19

I don't thinks change timed.max_skew to 120 can fix the issue.  The default valume is 30m.

• timed.max_skew is used to specify a high threshold
  If the time skew between the filer and the NTP server is greater than this value, the filer will not synchronize its clock.
  

The correct way is to setup a time server for filer.

[adamfox]

NFS sends all time/date info to the client in UNIX time (i.e. # of seconds since the epoch).  It is entirely up to the client to decide how to display that time.  This helps things issue with timezones, etc.