toasters

toasters@lists.teaparty.net

13515 discussions

seeing constant not responding messages
by Chris Caputo 21 Sep '97

21 Sep '97

I just the sent the following to support@netapp, but was also curious if anyone here had any insight. Is everyone on 4.1d happy? Chris ---------- Forwarded message ---------- Date: Thu, 18 Sep 1997 11:47:53 -0700 (PDT) From: Chris Caputo <ccaputo(a)alt.net> To: support(a)netapp.com Hi. We constantly (several times a minute) get the following and I have a feeling (because the drive lights go dark) it is affecting the performance of our NetApp box. At some point discussion on the toasters mailing list made me think that this was something that was going to be fixed after 4.0.1c, which is what we are running. Can you let us know if this is fixed in 4.1d? Should we upgrade regardless? Thanks, Chris Caputo President, Altopia Corporation PS: Here are the messages - they happen all of the time... Sep 18 11:43:51 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:52 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:43:55 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:56 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:43:57 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:57 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:43:59 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:59 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:03 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:04 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:07 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:07 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:08 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:08 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:09 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:09 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:11 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:12 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:14 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:14 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:21 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:21 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:25 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:25 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:26 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:26 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:30 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:30 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:32 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:33 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:36 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:36 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:36 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:37 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:39 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:39 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:40 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:40 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:42 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:42 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:43 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:44 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:44 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:45 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:49 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:49 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:51 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:51 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:56 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:56 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:01 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:01 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:01 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:02 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:03 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:03 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:04 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:05 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:06 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:06 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:11 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:11 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:15 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:16 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:19 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:19 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:24 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:24 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:35 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:35 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:41 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:42 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:47 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:48 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:48 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:49 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:49 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:50 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:50 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:50 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:04 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:05 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:13 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:13 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:15 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:15 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:33 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:33 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:39 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:40 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:42 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:42 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:43 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:43 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:44 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:44 tofu kernel: nfs server netapp1.alt.net:/home: is alive again

3 5

NetApp for mail spool?
by Gregory Gulik 18 Sep '97

18 Sep '97

I have a feeling this topic has been discussed to death, but here goes anyway: Has anyone had luck with using a NetApp for a mail spool? We did some tests, and although the locking worked fine most of the time, we did find that it dropped some messages for no reason whatsoever. In our case, the client machines are SPARCs running Solaris 2.5.1 Is there a problem with the locking on the NetApp, or are the Solaris libraries lying about the locks being in place and the writes taking place properly?

5 4

Re: NetApp for mail spool?
by Gregory Gulik 17 Sep '97

17 Sep '97

Do you have recommendations on where to find examples of code that incorporates this stonger locking you mention? -----Original Message----- From: David Schairer <njal(a)concentric.net> To: matthew zeier <mrz(a)3com.com> Cc: madhatta(a)mathworks.com <madhatta(a)mathworks.com>; greg(a)wwa.com <greg(a)wwa.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Wednesday, September 17, 1997 5:57 PM Subject: Re: NetApp for mail spool?

1 0

"Interrupted system call" to F230 news spool
by Brian Tao 17 Sep '97

17 Sep '97

One of my inn 1.4unoff4 news reader servers started throttling itself just today with "Interrupted system call writing article file" (happened twice in the past 24 hours). The spool is on an F230 running 4.0.3, 256MB of read cache and 4MB of write cache. The news server is an Ultra 170, 512MB of RAM, ~250 to 300 readers around peak times. The two are on a FDDI ring. The F230 hovers around 65% CPU usage, so I don't think that's the problem, but the Ultra is reporting 900 to 1200 packets per second both in and out of its FDDI interface. Half of its time is spent in the kernel, according to top(1). The mounts are NFSv3 over UDP. Would dropping back down to NFSv2 help any? I'm trying to determine if this is a network congestion problem, or an OS limitation (on either the Netapp or the Sun). -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

3 3

Filer response time
by Dave Heiland 15 Sep '97

15 Sep '97

I'm looking for a way to monitor the performance of my F630 filer, in addition to checking cpu levels, network traffic or other information provided by sysstat. Specifically, since the LADDIS benchmarks plot nfs ops versus response time, I was wondering how I can check the response time of my filer from the client's perspective. Is it just a matter of running nfsstat -m on clients and checking the round-trip times, or is there another command or program that can be used? Dave -- David J. Heiland Lucent Technologies dheiland(a)lucent.com CIO Department Malmesbury, England

1 0

Pardon my ignorance
by Kevin L. Gross 11 Sep '97

11 Sep '97

Sorry to send to the entire list, but I can't find the original message from this list telling me how to get off of it, if there was one. Could some kind soul overlook my ignorance and tell me the address to send to in order to remove myself from this list? Thanks, -Kevin

2 1

Re: snapshot scheduling
by mds46523＠ggr.co.uk 11 Sep '97

11 Sep '97

This sounds like another task that would be easier if we could load servlets onto the filers. On Sep 11, 6:05, Daniel Quinlan wrote: > Subject: snapshot scheduling > One of our filers has high data turn-around so I have limited the > snapshot lifetime to 2 days (the default) to keep usage at about 10%. > We use 4 days on our other filer because it experiences a lower rate of > data turn-around. > > > snap list > working........................ > %/used %/total date name > ---------- ---------- ------------ -------- > 1% ( 1%) 0% ( 0%) Sep 10 20:01 hourly.0 > 3% ( 3%) 2% ( 2%) Sep 10 16:01 hourly.1 > 5% ( 3%) 4% ( 2%) Sep 10 12:01 hourly.2 > 6% ( 3%) 5% ( 2%) Sep 10 08:01 hourly.3 > 8% ( 4%) 6% ( 3%) Sep 10 00:01 nightly.0 > 8% ( 4%) 6% ( 3%) Sep 09 20:01 hourly.4 > 10% ( 4%) 7% ( 3%) Sep 09 16:02 hourly.5 > 12% ( 5%) 10% ( 3%) Sep 09 00:01 nightly.1 > > Unfortunately, 2 days means that if someone deletes a file on Friday, it > will be gone by the next work day, Monday. There is also a lower rate > of data turn-around on the weekend. 3 days would be ideal, except on > weekdays where it can sometimes push the snapshot usage higher than I > want. > > Is there some way (other than a remote cron job twice a week) to acheive > what I want -- variable snapshot lifetimes according to the day of the > week? > > If not, it would be a nice feature. Either that, or options to force > deletion of n number of nightly snapshots (over m days old) when > snapshot usage goes over some percentage. > > Dan > > -- > Daniel Quinlan (at work) Linux, our last best hope for Unix > quinlan(a)transmeta.com http://www.pathname.com/~quinlan/ > ... > (Got BOFH? Looking for good ones.) >-- End of excerpt from Daniel Quinlan -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. PTP: What sheeplike qualities should you be developing?

1 0

snapshot scheduling
by Daniel Quinlan 11 Sep '97

11 Sep '97

One of our filers has high data turn-around so I have limited the snapshot lifetime to 2 days (the default) to keep usage at about 10%. We use 4 days on our other filer because it experiences a lower rate of data turn-around. > snap list working........................ %/used %/total date name ---------- ---------- ------------ -------- 1% ( 1%) 0% ( 0%) Sep 10 20:01 hourly.0 3% ( 3%) 2% ( 2%) Sep 10 16:01 hourly.1 5% ( 3%) 4% ( 2%) Sep 10 12:01 hourly.2 6% ( 3%) 5% ( 2%) Sep 10 08:01 hourly.3 8% ( 4%) 6% ( 3%) Sep 10 00:01 nightly.0 8% ( 4%) 6% ( 3%) Sep 09 20:01 hourly.4 10% ( 4%) 7% ( 3%) Sep 09 16:02 hourly.5 12% ( 5%) 10% ( 3%) Sep 09 00:01 nightly.1 Unfortunately, 2 days means that if someone deletes a file on Friday, it will be gone by the next work day, Monday. There is also a lower rate of data turn-around on the weekend. 3 days would be ideal, except on weekdays where it can sometimes push the snapshot usage higher than I want. Is there some way (other than a remote cron job twice a week) to acheive what I want -- variable snapshot lifetimes according to the day of the week? If not, it would be a nice feature. Either that, or options to force deletion of n number of nightly snapshots (over m days old) when snapshot usage goes over some percentage. Dan -- Daniel Quinlan (at work) Linux, our last best hope for Unix quinlan(a)transmeta.com http://www.pathname.com/~quinlan/ ... (Got BOFH? Looking for good ones.)

1 0

Re: SCSI shelf faults?
by sirbruce＠ix.netcom.com 10 Sep '97

10 Sep '97

On 09/10/97 16:47:03 you wrote: >Sorry, I guess I should have said that I have 1 chain. Physically there >are two shelves. NetApp engineer installed the shelves. I suppose he >could have gotten it wrong. This is especially likely with new products with a limitation that is new but not widely advertised. But it's easy to check... just run in there and see if they are connected to the card or to the secondary connector on the back of the chasis. (sysconfig -v may or may not report the right stuff if it's miscabled. Bruce

1 0

Re: SCSI shelf faults?
by sirbruce＠ix.netcom.com 10 Sep '97

10 Sep '97

On 09/10/97 14:22:11 you wrote: > >I just received the following: > >Wed Sep 10 14:00:00 EST [statd]: *** NOTICE *** > Fault previously reported on SCSI storage shelf attached > to slot 8a has been corrected. >Wed Sep 10 14:00:39 EST [statd]: *** NOTICE *** > Fault reported on SCSI storage shelf attached to slot 8a. > Please check fan and power on shelf. >Wed Sep 10 14:00:41 EST [asup_main]: System Notification mail sent > >What the heck is going on? The first message says that the fault previously >reported was corrected. There was no fault previously reported, and then a >fault gets reported. This is a 630 with a single shelf. Should I be >worried about this? Is the single shelf attached to 8b on the SCSI card? I believe the instructions say it has to be attached to 8a first. I might be wrong, but the message is very similar to those I've seen if you have the shelves cabled incorrectly. I've never seen a system with one shelf, but I recall than on a system with 4 shelves (2 chains) you couldn't, for example, put one on one SCSI card and one on the other SCSI card. The 630 with the new shelves is much more sensitive to this than previous filer models. It shouldn't be a problem in normal operation, but it could result in the filer getting confused if there is a disk failure or you try to do a hot swap of a drive, etc. Bruce

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters