toasters

toasters@lists.teaparty.net

13531 discussions

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

SCSI shelf faults?
by rasmus＠bellglobal.com 10 Sep '97

10 Sep '97

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? The only thing I did that might have affected it was to set the time on the box. It was off by 9 hours. At around 13:35 I set the time to 13:35 and then when the 14:00 check rolled around it generated the above. -Rasmus

1 0

upgrading Pentium 90 on F330
by Daniel Quinlan 10 Sep '97

10 Sep '97

Is it possible to upgrade the Pentium 90 chip on an F330? (Haven't opened mine in a while... Is it in a ZIF socket?) Has anyone tried or looked into this? slot 0: System Board 90 MHz (NetApp System Board I rev-b) Memory Size: 256 MB I know it is possible to upgrade the entire head or move the disks to another array with the same size disks. 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.)

3 4

Re: raid swap and dump problem
by sirbruce＠ix.netcom.com 08 Sep '97

08 Sep '97

On 09/08/97 19:44:13 you wrote: > > >Hi, > >When doing a `raid swap' I get this warning, > >> raid swap >** WARNING ** >You can NOT swap a disk into or out of the system: >a dump is currently running on a local tape device >and you must wait until the dump is completed, or abort the >dump before reissuing the "raid swap" command. This particular limitation shouldn't happen if your tape drive isn't on the same bus as your disks, which is just about every system Netapp has shipped in recent years. However, that "bug" wasn't fixed until 4.0 or 4.1, I think. >But there is no dump running, the last dump was aborted, > >DUMP: ran out of tape, and can't ask questions when run via "rsh". >DUMP: The ENTIRE dump is aborted. > >Is there a lockfile which should be removed? How do I abort the >dump I can't find? Yes, unfortunately, there is no "dump abort" command on the filer the clear up such things. There might be a way to abort NDMP sessions, but basically the best thing for you to do is reboot. (There's no lockfile; the state is in memory.) An easy way to reproduce this is have an rsh dump running from a remote client which then crashes. Bruce

1 0

NFS bursting is killing us
by Christoph Doerbeck 08 Sep '97

08 Sep '97

In recent tests to uncover performance issues with a newer F330 running 4.0.1c, our network snooper-dude has revieled that the toaster is not interleaving the NFS packets very well. Thus, client machine A gets a bunch of i/o, then B, then back to A, then C, etc... It feels like the NFS "daemon" is running in non-pre-emptive task-switching mode. (Did someone slip MS Windoz code in here ?) The older 330's (still running 3.x) do not exhibit this behaviour. Any comments/ideas would sure be appreciated... The toaster in question is running 4.0.1c as mentioned, with CIFS and HTTP disabled. - C. Doerbeck

1 0

Jump to page:

2026

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