We have a F740 Netapps Filer which has filesystems NFS mounted on to a Sun Unix server (Solaris 2.7).
When new files are created on the NFS mounted filesystem on the filer, the time stamp does not show-up ("ls -la") until later; it looks as though there is some event that triggers the display of the time-stamp.
Wondering if anyone has come across the same problem/feature!
We have a F740 Netapps Filer which has filesystems NFS mounted on to a Sun Unix server (Solaris 2.7).
When new files are created on the NFS mounted filesystem on the filer, the time stamp does not show-up ("ls -la") until later; it looks as though there is some event that triggers the display of the time-stamp.
Wondering if anyone has come across the same problem/feature!
This is because the time is not synchronized between the filer and the solaris host typically. Curious to find out if the timestamp appears when the time on the solaris host catches up to the time on the filer?
Rashid.Bawa@BMO.com (Bawa Rashid) writes:
We have a F740 Netapps Filer which has filesystems NFS mounted on to a Sun Unix server (Solaris 2.7).
When new files are created on the NFS mounted filesystem on the filer, the time stamp does not show-up ("ls -la") until later; it looks as though there is some event that triggers the display of the time-stamp.
What do you mean when you say that the time stamp "does not show up" ? Give us some example output.
If your filer clock was significantly in advance of your clients' clocks, then you might see the time displayed as "MON dd yyyy" rather than as "MON dd hh:mm", until the clients catch up.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
Nobody seems to be coming right out and saying it, so...
Newcomers to NFS may not be aware that you really need to set up some kind of time synchronization between NFS clients and servers. It's Just The Right Thing To Do. Without time synchronization, users get confused, make doesn't work when you need it to, and log analysis becomes needlessly difficult.
The NTP daemon that's built into ONTAP 5.x works perfectly well in spite of the fact that it is apparently implemented in Java. And, on the NFS-client side, xntpd's are cheap and plentiful.
If NTP isn't an option, do something...some cron/rsh/rdate hackery, maybe. And then start making NTP an option. Here's a start:
http://www.eecis.udel.edu/~ntp/hardware.html http://www.eecis.udel.edu/~mills/ntp/servers.htm
Brian brice@gnac.com
you can do rdate without rsh.
timed.proto ntp or rdate timed.max_skew 30m timed.log off timed.max_skew 30m timed.sched hourly timed.servers timehost timed.enable on
--tmac
brice@gnac.com wrote:
Nobody seems to be coming right out and saying it, so...
Newcomers to NFS may not be aware that you really need to set up some kind of time synchronization between NFS clients and servers. It's Just The Right Thing To Do. Without time synchronization, users get confused, make doesn't work when you need it to, and log analysis becomes needlessly difficult.
The NTP daemon that's built into ONTAP 5.x works perfectly well in spite of the fact that it is apparently implemented in Java. And, on the NFS-client side, xntpd's are cheap and plentiful.
If NTP isn't an option, do something...some cron/rsh/rdate hackery, maybe. And then start making NTP an option. Here's a start:
http://www.eecis.udel.edu/~ntp/hardware.html http://www.eecis.udel.edu/~mills/ntp/servers.htm
Brian brice@gnac.com
-- ******All New Numbers!!!****** ************* *************
Timothy A. McCarthy --> System Engineer, Eastern Region Network Appliance http://www.netapp.com 240-268-2034 Office \ / Page Me at: 240-268-2001 Fax / 888-971-4468
+-- "Timothy A. McCarthy" tmac@netapp.com once said: | you can do rdate without rsh. | | timed.proto ntp or rdate | timed.max_skew 30m | timed.log off | timed.max_skew 30m | timed.sched hourly | timed.servers timehost | timed.enable on
Not prior to DOT 5.3 AFAIK.
We use rdate via rsh on a couple of our 5.2 DOT boxes.
Oz
You are right on that. This was all placed into being as of 5.3. It does work very nicely for either NTP or rdate.
--tmac
Ozzie Sabina wrote:
+-- "Timothy A. McCarthy" tmac@netapp.com once said: | you can do rdate without rsh. | | timed.proto ntp or rdate | timed.max_skew 30m | timed.log off | timed.max_skew 30m | timed.sched hourly | timed.servers timehost | timed.enable on
Not prior to DOT 5.3 AFAIK.
We use rdate via rsh on a couple of our 5.2 DOT boxes.
Oz
-- ******All New Numbers!!!****** ************* *************
Timothy A. McCarthy --> System Engineer, Eastern Region Network Appliance http://www.netapp.com 240-268-2034 Office \ / Page Me at: 240-268-2001 Fax / 888-971-4468
On Wed, 2 Aug 2000 brice@gnac.com wrote:
The NTP daemon that's built into ONTAP 5.x works perfectly well in spite of the fact that it is apparently implemented in Java. And,
Actually, we've found the time to be kept pretty horribly on our filers, even with the timed options enabled. We see time skews of upto a few *seconds* with NetApp's implementation of NTP. Being out of sync that much royally blows up our software builds.
# grep skew mess* | awk '{print $15}' | sort -nr | head -5 +2.851 +2.514 +2.406 +2.146 +2.135 # egrep skew mess* | awk '{print $15}' | sort -n | head -5 -2.705 -2.456 -2.244 -2.146 -2.051
I was under the impression that NTP very gently slews the time to keep it in sync, rather than skewing the time in quantum jumps. It's almost as if NetApp's implementation is just a regularly scheduled cron-like ntpdate via Java rather than a robust xntpd daemon continually running and continually adjusting the clock.
I have an RFE open on this issue, which support claims will be fixed in 5.3.7.
24614 RFE: NTP/timed: knob for minimum skew requested
(Thanks Dave Z. and Rod B.!)
This will make the threshold of 50 ms adjustable, the threshold between when the filer's time is "close enough" and when it needs to be reset. However, it does not solve the problem of having, for lack of a better adjective, a "true" NTP daemon running. Perhaps that is very difficult in a realtime OS as opposed to the time sharing desktop or server UNIX OS's to which we are accustomed. 50 ms is pretty reasonable as is, but even at that setting we are getting multi-second skews.
Oh, I also have an RFE/burt/case (I can't find it in my notes) to improve the syslog messages when a time adjustment is made. For instance, we had to do a head swap and the time on the new head was way off:
Wed Jul 5 12:05:25 EDT [Java Thread]: TimeDaemon: NTP server 'time' reports that the time is Wed Jul 05 20:05:53 EDT 2000, but the filer thinks the time is Wed Jul 05 12:05:25 EDT 2000. This time offset is too large to cause us to modify the time automatically (max allowable skew: 600.000 secs). If the time reported by the time server is correct, set the filer time using the 'date' command.
Wed Jul 5 20:06:31 EDT [rc]: Time changed (via "rdate time") to Wed Jul 5 20:06:31 EDT 2000
The "time changed" message is...ah...nearly useless. How big was the time change? It would be more useful to have the timestamp be the *old* time, and the new time recorded; the difference is then the skew induced by rdate.
Okay, two complaints per post is enough. I won't get into the fact that the timed service litters the messages file with notifications. I think someone else pointed out recently the desire for a more robust syslog facility logging. I'd like the ability to put these into messages.info or messages.non-critical or something.
However, taking a historical, big-picture view, having the timed options is a significant improvement from the "old days" of having our admin host rsh the rdate command via cron. <*cough*Kludge!*cough*>
Until next time...
The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
Todd wrote:
Actually, we've found the time to be kept pretty horribly on our filers, even with the timed options enabled. We see time skews of upto a few *seconds* with NetApp's implementation of NTP.
Hmm, how odd. I haven't seen that. From an F630 running 5.3.2D3:
$ grep skew mess* | awk '{print $15}' | sort -nr | head -5 +0.544 +0.205 +0.201 +0.194 +0.190 $ grep skew mess* | awk '{print $15}' | sort -n | head -5 -0.219 -0.218 -0.213 -0.212 -0.212
And from an F740 running 5.3.4R3:
$ grep skew mess* | awk '{print $15}' | sort -nr | head -5 +0.184 +0.171 +0.171 +0.170 +0.170 $ grep skew mess* | awk '{print $15}' | sort -n | head -5 -0.191 -0.103 -0.102 -0.094 -0.085
Could you have a stinko time signal?
Anyway, I like your RFE too.
Brian
Todd wrote:
Actually, we've found the time to be kept pretty horribly on our filers, even with the timed options enabled. We see time skews of upto a few *seconds* with NetApp's implementation of NTP.
On Fri, 4 Aug 2000 brice@gnac.com wrote:
Could you have a stinko time signal?
Unlikely. We got a stratum 2 server and have no problems with the hundreds of clients that run xntpd daemons. I seem to recall someone (on the list or from NetApp) saying that heavily loaded filers may have trouble keeping good time. We certainly beat the <insert your favorite 4-letter word here> out of 'em, so this could be it.
Due to a spate of recent problems, we've had a bunch of motherboards replaced, too, to no avail, so I doubt also we just got unlucky with a bad oscillator.
Until next time...
The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
-
Bawa, Rashid -
brice＠gnac.com -
Chris Thompson -
Mike Smith -
Ozzie Sabina -
Timothy A. McCarthy -
Todd C. Merrill