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
