toasters

toasters@lists.teaparty.net

1 participants
13523 discussions

High Performance volume configuration
by Graydon Dodson 10 Oct '00

10 Oct '00

> I also had a 760 survive doing 17,000 nfs ops/second once. ... When running compiles, it is not unusual for us to see numbers over 22,000 on the op-panel of our 760. Anyone know where the top end of an 840 is? Support has been unable to answer that one for us. So in our move to an 840 I want to configure it's volume for maximum performance. The ground rules are two FC-AL adapters, seven full trays of 18G drives. All one volume is very desirable. Now the SPECsfs97 benchmark on the 840 states: * The F1 filesystem was composed of two RAID groups, each containing 17 data disks and one parity disk. Two spare disks were present * The F1 filesystem was striped across both disk controllers Since I have to assume that NetApp would use a high performance architecture for the benchmark I am guessing that this is the way to go, but there is quite a bit of detail missing. Is it a good or bad idea to split a raid group over two FC-AL interfaces? What does "striped across both disk controllers" mean? If there are spare disks (same size) on both FC-AL interfaces and a disk fails Which one is used to rebuild? (Same FC-AL or random choice) Is it a good or bad idea to split a volume over multiple FC-AL interfaces? The need for speed Graydon Dodson (606) 232-6483 grdodson(a)lexmark.com Lexmark International Inc.

3 4

RE: 32-bit uptime counter?
by Strange, Steve 10 Oct '00

10 Oct '00

I think the fix first appears in 6.0 (I happened to be the one who fixed it). We now use a 64-bit millisecond counter. Not sure how many years that is offhand, but I think we're ok for a while. Brian -- your quoted mail msg below is the text of the bug report :-). Thanks!! Steve > -----Original Message----- > From: Brian Tao [mailto:taob@risc.org] > Sent: Monday, October 09, 2000 9:53 PM > To: toasters(a)mathworks.com > Cc: Yoder, Alan > Subject: RE: 32-bit uptime counter? > > > On Wed, 19 May 1999, Yoder, Alan wrote: > > [Guy Harris writes]... > > > [Brian Tao writes]... > > > > Still running good ol' 4.2a on an F230: > > > > > > > > Sun Apr 18 21:00:00 EDT [statd]: 9:00pm up 497 days, > 1:10 407777519 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > Sun Apr 18 22:00:00 EDT [statd]: 10:00pm up 497 days, > 2:10 408458997 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > Sun Apr 18 23:00:00 EDT [statd]: 11:00pm up 42 mins, > 409036765 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > Mon Apr 19 00:00:00 EDT [statd]: 12:00am up 1:42 > 409494263 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > > > > > This looks like 2^32 ticks elapsed (about 42949673 > seconds)... > > > > > > Yes, the tick counter is 32 bits in 4.2a: > > > > > > tooting$ egrep sk_tics ../sk/*.h > > > ../sk/sk.h:extern VOLATILE int4 sk_tics; /* > > > number of ticks since boot */ > > > > > > > is this one of the counters being increased to 64 bits? > > > > > > It's not been increased in size yet; I don't know if it's > one of the > > > ones we plan to boost in size. > > > > It is now. > > Say, which release was the change incorporated? I'm gettin' tired > of seeing my uptime counters roll. ;-) > > | Sun Oct 1 00:00:01 EDT [asup_main]: System Notification mail sent > | Sun Oct 1 01:00:00 EDT [statd]: 1:00am up 496 days, > 16:35 1845869853 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 01:00:00 EDT [raid_scrub_admin]: Beginning disk > scrubbing... > | Sun Oct 1 02:01:03 EDT [statd]: 2:01am up 496 days, > 17:35 1846202045 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 parity > inconsistencies > | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 media errors > | Sun Oct 1 03:00:32 EDT [consumer]: Disk scrubbing finished... > | Sun Oct 1 03:00:42 EDT [statd]: 3:00am up 496 days, > 18:34 1846455096 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 04:00:00 EDT [statd]: 4:00am up 496 days, > 19:33 1846520843 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 05:00:00 EDT [statd]: 5:00am up 496 days, > 20:34 1846581690 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 06:00:00 EDT [statd]: 6:00am up 496 days, > 21:34 1846983917 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 07:00:01 EDT [statd]: 7:00am up 496 days, > 22:34 1847368872 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 08:00:00 EDT [statd]: 8:00am up 496 days, > 23:33 1847430632 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 09:00:00 EDT [statd]: 9:00am up 497 days, 34 > mins, 1847493449 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 10:00:00 EDT [statd]: 10:00am up 497 days, > 1:34 1847553879 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 11:00:00 EDT [statd]: 11:00am up 6 mins, > 1847633991 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 12:00:00 EDT [statd]: 12:00pm up 1:06 > 1847697785 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 13:00:00 EDT [statd]: 1:00pm up 2:06 > 1847760829 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 14:00:00 EDT [statd]: 2:00pm up 3:06 > 1847824644 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 15:00:00 EDT [statd]: 3:00pm up 4:06 > 1847886612 NFS ops, 0 CIFS ops, 0 HTTP ops > > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" >

1 0

RE: 32-bit uptime counter?
by Brian Tao 10 Oct '00

10 Oct '00

On Wed, 19 May 1999, Yoder, Alan wrote: > [Guy Harris writes]... > > [Brian Tao writes]... > > > Still running good ol' 4.2a on an F230: > > > > > > Sun Apr 18 21:00:00 EDT [statd]: 9:00pm up 497 days, 1:10 407777519 NFS ops, 0 CIFS ops, 0 HTTP ops > > > Sun Apr 18 22:00:00 EDT [statd]: 10:00pm up 497 days, 2:10 408458997 NFS ops, 0 CIFS ops, 0 HTTP ops > > > Sun Apr 18 23:00:00 EDT [statd]: 11:00pm up 42 mins, 409036765 NFS ops, 0 CIFS ops, 0 HTTP ops > > > Mon Apr 19 00:00:00 EDT [statd]: 12:00am up 1:42 409494263 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > > > This looks like 2^32 ticks elapsed (about 42949673 seconds)... > > > > Yes, the tick counter is 32 bits in 4.2a: > > > > tooting$ egrep sk_tics ../sk/*.h > > ../sk/sk.h:extern VOLATILE int4 sk_tics; /* > > number of ticks since boot */ > > > > > is this one of the counters being increased to 64 bits? > > > > It's not been increased in size yet; I don't know if it's one of the > > ones we plan to boost in size. > > It is now. Say, which release was the change incorporated? I'm gettin' tired of seeing my uptime counters roll. ;-) | Sun Oct 1 00:00:01 EDT [asup_main]: System Notification mail sent | Sun Oct 1 01:00:00 EDT [statd]: 1:00am up 496 days, 16:35 1845869853 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 01:00:00 EDT [raid_scrub_admin]: Beginning disk scrubbing... | Sun Oct 1 02:01:03 EDT [statd]: 2:01am up 496 days, 17:35 1846202045 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 parity inconsistencies | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 media errors | Sun Oct 1 03:00:32 EDT [consumer]: Disk scrubbing finished... | Sun Oct 1 03:00:42 EDT [statd]: 3:00am up 496 days, 18:34 1846455096 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 04:00:00 EDT [statd]: 4:00am up 496 days, 19:33 1846520843 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 05:00:00 EDT [statd]: 5:00am up 496 days, 20:34 1846581690 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 06:00:00 EDT [statd]: 6:00am up 496 days, 21:34 1846983917 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 07:00:01 EDT [statd]: 7:00am up 496 days, 22:34 1847368872 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 08:00:00 EDT [statd]: 8:00am up 496 days, 23:33 1847430632 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 09:00:00 EDT [statd]: 9:00am up 497 days, 34 mins, 1847493449 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 10:00:00 EDT [statd]: 10:00am up 497 days, 1:34 1847553879 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 11:00:00 EDT [statd]: 11:00am up 6 mins, 1847633991 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 12:00:00 EDT [statd]: 12:00pm up 1:06 1847697785 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 13:00:00 EDT [statd]: 1:00pm up 2:06 1847760829 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 14:00:00 EDT [statd]: 2:00pm up 3:06 1847824644 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 15:00:00 EDT [statd]: 3:00pm up 4:06 1847886612 NFS ops, 0 CIFS ops, 0 HTTP ops -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

RE: MRTG ?
by Thompson, Tim 09 Oct '00

09 Oct '00

> To anyone using MRTG (Multi Router Traffic Grapher): What is exactly is > the difference between the "CIFS Read/Write" and the "CIFS Other" > operations? The "CIFS Other" operations include a variety of operations such as: Login type messages echo tdis negprot login logout tconX NT admin type messages NTTransIoctl NTTransSetSec NTTransQuerySec NTCancel CN NTCancel Other ...Tim Thompson...Network Appliance, Inc...

1 0

MRTG ?
by nick.mayrath＠webmd.net 09 Oct '00

09 Oct '00

To anyone using MRTG (Multi Router Traffic Grapher): What is exactly is the difference between the "CIFS Read/Write" and the "CIFS Other" operations? Thanks in advance, Nick

1 0

Low SMB throughput
by Alfred Lerch 09 Oct '00

09 Oct '00

Friends, we are running a F740 in a heterogenous NFS/SMB environment. While we are completely happy on NFS performance SMB performance is not what we would like it to be. But it is only on some Win95 and NT 4.0 where then throughput is low, other Win95 and NT 4.0 systems with the same configuration are fine (as far as you are able to state that two Windows installations are the same). Looking to our 3Com switches shows us that it is not an issue on the ethernet level. I personally guess that it is a protocol issue between the NetApp and Microsoft implementation of CIFS/SMB/NetBIOS over TCP/IP but I'm unable to verify this. Any ideas where we might start looking ? Has anyone experienced a similar issue ? regards alfred -- -- \\\\\/// / ^ _ \ ( (o) (o) ) --- That's all folks --- +=oOOO=====(_)=====OOOo==========================================+ |Alfred Lerch Mentor Graphics Deutschland GmbH| |Network & System Administrator Elsenheimer Str. 41 - 43| |IT - Business Support Team Munich D-80687 Muenchen, Germany| |email: alfred_lerch(a)mentor.com Fax : +49 89 57096-400| |Tel. : +49 89 57096-241 Mobile: +49 172 8915200| | | |Helpdesk IT Central Europe in Munich | |Tel. : +49 89 57096-110 internal: 777| |email: helpdesk_dem(a)mentor.com | +=============Oooo.==============================================+ .oooO ( ) ( ) ) / \ ( (_/ \_)

2 1

RE: Mac G4 with NetApp
by Benn, Paul 09 Oct '00

09 Oct '00

It should work fine but you need to make sure that it's has the appropriate client installed. What OS are you on (OSX supports NFS)? Are you running the Dave client for CIFS access? www.thursby.com -----Original Message----- From: Mathew Anderson [mailto:mathew@nm.net] Sent: Monday, October 09, 2000 9:59 AM To: toasters(a)mathworks.com Subject: Mac G4 with Netapp Has anyone tried to get a G4 to mount a netapp share? We have the netapp setup with both nfs and cifs, and we are using a PDC. Any pointers on where to start? (apples KB does not help at all).. Thanks -Mathew Mathew Anderson Systems Administration NM Technet Oso Grande Technologies, Inc. mathew(a)nm.net mathew(a)osogrande.net

2 1

RE: mixing 18GB and 36GB drives
by Whitman, Matthew 09 Oct '00

09 Oct '00

If there is a 18GB drive available (or for that matter 2/4/9/etc.) The filer will take the appropriate drive size spare to rebuild that drive. In your example: > > I've got a filer with a shelf of 36's (one RG/volume) and two > >shelves of 18's (one RG/volume); each RG has a hot spare. The following would happen: 1) 18GB drive fails; the filer grabs the 18GB spare 2) 36GB drive fails; the filer grabs the 36GB spare 3) 18GB drive fails and rebuilds to the 18GB spare, you then lose another drive, the filer will grab the only remaining spare, the 36GB drive. I hope that clears things up. Regards, Matt - Matt Whitman - Consulting Systems Engineer Network Appliance, Inc. www.netapp.com 495 East Java Drive Sunnyvale, CA 94089 (408)822-6000 Corporate mattw(a)netapp.com - E-mail (408)822-6249 - Direct Dial (408)822-4406 - Fax -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Monday, October 09, 2000 9:48 AM To: Jamey Maze Cc: toasters(a)mathworks.com Subject: Re: mixing 18GB and 36GB drives On Mon, 9 Oct 2000, Jamey Maze wrote: > At 11:24 AM 10/9/00 -0400, Todd C. Merrill wrote: > > I've got a filer with a shelf of 36's (one RG/volume) and two > >shelves of 18's (one RG/volume); each RG has a hot spare. What I do ^^^^^^^^^^^^^^^^^^^^^^^ > If you have an 18GB drive fail and there are only 36GB hot spares, the > filer will automatically take a 36GB drive and begin rebuilding, but it What happens when there is both a 36 GB and an 18 GB hot spare available? Is is a crapshoot? Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

Mac G4 with Netapp
by Mathew Anderson 09 Oct '00

09 Oct '00

Has anyone tried to get a G4 to mount a netapp share? We have the netapp setup with both nfs and cifs, and we are using a PDC. Any pointers on where to start? (apples KB does not help at all).. Thanks -Mathew Mathew Anderson Systems Administration NM Technet Oso Grande Technologies, Inc. mathew(a)nm.net mathew(a)osogrande.net

1 0

Re: budtool
by Louis Brune 09 Oct '00

09 Oct '00

My thanks. I've received several replies. The summary is: Just make the path be something like /vol/myvolume which I was already doing. One person asked about existence of /etc on each volume. Yup. It's there, and writable by root (who runs the backup). The Budtool support folk have had this question pending for a while; I've just stirred them up again this morning, I hope.- Apparently, I'm just unlucky. (I even intended to send this out Friday afternoon). -- Moderation in all things, except love. Louis

1 0

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