toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

filer Olympics
by Todd C. Merrill 13 Jul '00

13 Jul '00

;) Had a humorous thought...we've had to replace a lot of motherboards and memory in the last 2 weeks for various reasons, and I've been getting pretty good at it. I was looking back at the logs at the actual downtime for these various tasks. My best times so far have been, where "downtime" is measured from the filer messgages: System shut down with "halt" command. to NetApp Release 5.w.xRyPz boot complete. memory swap: 3 minutes, 57 seconds [0] motherboard swap: 15 minutes, 54 seconds [0] [1] I've broken the "4-minute mile" for the former, but not the "15 minute" mark for the latter. Next time. Or, maybe a contestant on "Fix That Filer" ala "Name That Tune": FilerAdmin1: I can fix that filer in 6 minutes. FilerAdmin2: I can fix that filer in 5 minutes. FilerAdmin3: I can fix that filer in 4 minutes. Wink Martindale: Okay, FilerAdmin3....fix that filer! Okay, time for some breakfast and some serious work now... [0] This includes a 32 second "penalty" for upping 4 links on a vif. [1] Three PCI cards: NVRAM, FCAL, quad ethernet 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 ---

9 10

RE: filer Olympics
by jeff.mohler＠netapp.com 13 Jul '00

13 Jul '00

*grin* Sounds like some of this chest thumping needs backed up with Netapp Certification! http://www.netapp.com/education/ Of course..I just wanna take Todd to dinner..thats all. -----Original Message----- From: Derek Kelly [mailto:derek.kelly@genomecorp.com] Sent: Thursday, July 13, 2000 11:13 AM To: Todd C. Merrill Cc: toasters(a)mathworks.com Subject: Re: filer Olympics .... perhaps first prize should be a job offer from NetApp? ;) Cheers, Derek Kelly Genomecorp On 7/13/00 at 8:24 AM, tmerrill(a)mathworks.com (Todd C. Merrill) wrote: > > ;) > > Had a humorous thought...we've had to replace a lot of motherboards and > memory in the last 2 weeks for various reasons, and I've been getting > pretty good at it. I was looking back at the logs at the actual > downtime for these various tasks. My best times so far have been, where > "downtime" is measured from the filer messgages: > > System shut down with "halt" command. > > to > > NetApp Release 5.w.xRyPz boot complete. > > > memory swap: 3 minutes, 57 seconds [0] > motherboard swap: 15 minutes, 54 seconds [0] [1] > > I've broken the "4-minute mile" for the former, but not the "15 minute" > mark for the latter. Next time. > > > Or, maybe a contestant on "Fix That Filer" ala "Name That Tune": > > FilerAdmin1: I can fix that filer in 6 minutes. > FilerAdmin2: I can fix that filer in 5 minutes. > FilerAdmin3: I can fix that filer in 4 minutes. > Wink Martindale: Okay, FilerAdmin3....fix that filer! > > Okay, time for some breakfast and some serious work now... > > > [0] This includes a 32 second "penalty" for upping 4 links on a vif. > [1] Three PCI cards: NVRAM, FCAL, quad ethernet > > 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

RE: Max SCSI cable length
by mds＠gbnet.net 12 Jul '00

12 Jul '00

On Wed 12 Jul, 2000, Jay Orr <orrjl(a)stl.nexen.com> wrote: > speed of max single max HVD length Max LVD length > fastest device > --------------------------------------------------------------- > 5 MHZ (Scsi1) 6M 25M 12M > 10MHZ (S2 Fast) 3M 25M 12M > 20MHZ (Ult. F20) 1.5M 25M 12M > 40MHZ (Ult2 F40) <nr> 12M 12M > Those are closer to the numbers I was expecting people to come up with. > I'm supprised the F7**'s are HVD (didn't investigate it myself). Seems > like HVD is going [slowly] by the wayside... Well tape drives, like CDROM drives, are slow to match the trends that disks and SCSI-host-adapters set. Even now you can usually feed two high-end tape drives (DLT, AIT, Exabyte) off one Fast, Wide SCSI bus. HVD FW SCSI has been around and widely used for, oh, about 5-6 years I reckon, so it's well-proven, reliable, and R&D-amortised technology. There's a hell of a lot of equipment in the world using HVD, at least I've come across a lot in server rooms and places where, until fibre and LVD came along, it was either HVD FW SCSI or something proprietary from IBM or DEC or you couldn't do the job at all. Until fibre-attached tape drives start selling in higher volume than HVD FW SCSI I don't think I'd claim it to be falling by the wayside. >-- End of excerpt from Jay Orr -- -Mark ... an Englishman in London ...

1 0

RE: Max SCSI cable length
by steve.smart＠netapp.com 12 Jul '00

12 Jul '00

If I have got my facts right ... The LVD SCSI standard is listed as being able to support up to 25m. The HVD standard 5m. Right now the F7** series supports HVD and not LVD. So it seems 17ft is the thing. S -----Original Message----- From: Jeff Bryer [mailto:bryer@sfu.ca] Sent: 11 July 2000 23:07 To: toasters(a)mathworks.com Subject: Max SCSI cable length As we get closer to actually purchasing our new tape library, we've started to think about how things will physically fit in our machine room. According to the NetApp manual, it says the max SCSI length for connecting a tape drive is 17ft. Is that the absolute maximum? I've heard people talk about 25metres. I'm inclined to believe the manual but I would much rather believe 25metres. Otherwise we're going to have to get really creative connecting 4 separate machines (2 of which are F740s) to one tape library via 4 separate SCSI buses on the library (don't ask ;). -- Jeff Bryer bryer(a)sfu.ca Systems Administrator (604) 291-4935 Academic Computing, Simon Fraser University

2 1

Max SCSI cable length
by Jeff Bryer 12 Jul '00

12 Jul '00

As we get closer to actually purchasing our new tape library, we've started to think about how things will physically fit in our machine room. According to the NetApp manual, it says the max SCSI length for connecting a tape drive is 17ft. Is that the absolute maximum? I've heard people talk about 25metres. I'm inclined to believe the manual but I would much rather believe 25metres. Otherwise we're going to have to get really creative connecting 4 separate machines (2 of which are F740s) to one tape library via 4 separate SCSI buses on the library (don't ask ;). -- Jeff Bryer bryer(a)sfu.ca Systems Administrator (604) 291-4935 Academic Computing, Simon Fraser University

2 1

RE: volume/shelf containment
by Sam Schorr 11 Jul '00

11 Jul '00

Douglas, I think you are confusing "adapter" with "disk shelf". Unless you have 2 FCAL adapters in your filer, and have connected each shelf to its own adapter, you are not spanning adapters and thus not violating what the manual says. I have many filers with their full complement of disk shelves connecting to the 1 FCAL adapter on the filer head. I have RAID groups that span shelves as will happen when disk spare out. There is no performance penalty in this scenario. Sam Schorr Homestead.com ph: (650) 549-3152 fax: (650) 364-7329 sschorr(a)homestead-inc.com http://www.homestead.com Homestead: It's a new world. Make your place. -----Original Message----- From: Douglas Ritschel [mailto:Douglas.Ritschel@fnc.fujitsu.com] Sent: Monday, July 10, 2000 12:20 PM To: Bruce Sterling Woodcock Cc: toasters(a)mathworks.com Subject: Re: volume/shelf containment This is what the book says: "-Write performance will suffer when a RAID group spans more than one FC-AL or SCSI adapter. -Keep all drives assigned to a RAID group on the same adapter whenever posible. -There is an approximate 10% decrease in write performance when the filer attempts to write to a RAID group spanning two adapters. This is due to inherent limitations in the PCI bus." Bruce Sterling Woodcock wrote: > > Unless I misunderstand some of the bus issues involved, the 10% > performance hit would only occur on writes, and since writes are grouped > and it is unlikely that you are writing to the drives ever second, you'll > never > notice it. > > Reads come off individual disks as needed, so it doesn't matter which > controller they are on. (I guess if you needed to read a whole stripe at > once there's a potential hit, but I'm not sure that necessary.) The point > is, with two volumes you're using both controllers anyway. > > Bruce -- Douglas Ritschel Fujitsu Network Communications Two Blue Hill Plaza, Sixth Floor P.O. Box 1609 Pearl River, NY 10965 Ph: 914.731.2101 Fx: 914-731-2011 Douglas.Ritschel(a)fnc.fujitsu.com

6 7

RE: F740 filesystem restore throughput?
by kevin graham 11 Jul '00

11 Jul '00

On Mon, 10 Jul 2000 johnk(a)netapp.com wrote: > It's actually the other way around - packet checksum offloading is a feature > offered by the current (Intel) gigabit cards that the Alteon cards used > previously did not support. The option I was think of was 'udp_lg_dgram.xmit_cksum.offload' (ferreted off of ntap spec benchmark notes).. Obviously I had the wrong impression about what this controlled. What was it? > options cksum_offload.gbeII on Will enable it today, thanks. ..kg..

1 0

Re: volume/shelf containment
by mds＠gbnet.net 11 Jul '00

11 Jul '00

On Mon 10 Jul, 2000, Frank Smith <fsmith(a)hoovers.com> wrote: > Wouldn't it be at least slightly risky to pull all your spares plus one > of your data drives for the duration of a rebuild? Yes. Therefore it's not really recommended. You can of course replace all the spares as soon as the rebuild is suitably underway - which should allow for further rebuilds on other RAID groups if you have a multi-disk failure of that type. If you have a real disk failure in the RAID group you just artificially pulled a disk from, then you start writing the apology emails and calling the ops to bring the tapes back on-site.. Overall, this creates additional work, and as laziness is a virtue, I, personally, wouldn't go pulling disks to neaten up my RAID groups. (similar case: because the filer uses RAID4 not RAID5, and is a pretty smart cookie, you can achieve Great Things(tm) by not having a spare around and pulling the parity disk in each RAID group in a volume... the risk/benefit analysis is an exercise for the reader) > Frank >-- End of excerpt from Frank Smith -- -Mark ... an Englishman in London ...

3 2

Fw: NDMPD
by Ferdie Mazon 11 Jul '00

11 Jul '00

Sorry for the confusion, here is a copy of the rc file. #Regenerated by registry Fri May 26 17:19:40 PDT 2000 #Auto-generated by setup Tue May 2 19:06:59 GMT 2000 hostname srglfs3 ifconfig e0 `hostname`-e0 mediatype 100tx-fd netmask 255.255.0.0 ifconfig e3a `hostname`-e3a mediatype 100tx-fd netmask 255.255.0.0 route add default 10.0.0.160 1 routed on options dns.domainname brandes.com options dns.enable on options nis.enable off savecore exportfs -a nfs on options autosupport.enable on ndmpd on ndmpd status ----- Original Message ----- From: "Jim Ward" <jimw(a)worksta.com> To: <ferdie(a)san.rr.com> Sent: Friday, July 07, 2000 11:33 AM Subject: Re: NDMPD > Ferdie, > > Have you tried "ndmpd on" in lower case? > > Jim > > -- > __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ > | | > | EMail: jimw(a)worksta.com Tel: +1 (603) 672-8600 x232 | > | WWW: http://www.worksta.com Fax: +1 (603) 672-3154 | > | Post: Workstation Solutions, Inc., Five Overlook Drive, Amherst, NH 03031 | > | | > | * Data Backup and Recovery Solutions for Your Peace of Mind * | > | __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |

7 9

Toasters list turnround sluggishness
by Chris Thompson 11 Jul '00

11 Jul '00

Having been caught out again by asking a question when there was a list message already sent that answered it, I took a look at my mail folders to see why turnround on the list seems to be so sluggish. There doesn't seem to be any appreciable delay in messages getting to mathworks.com, or being processed by Majordomo. It's the time they sit on the queue at smtp.mathworks.com before being sent out that seems to be the problem: it's typically over 90 minutes. A typical (recent) example: | Received: from [144.212.95.101] (helo=smtp.mathworks.com) | by virgo.cus.cam.ac.uk with esmtp (Exim 3.15 #3) | id 13BmNV-00029g-00 | for cet1(a)cus.cam.ac.uk; Mon, 10 Jul 2000 23:50:18 +0100 | Received: (from majordom@localhost) | by smtp.mathworks.com (8.9.3/8.9.3) id RAA04028; | Mon, 10 Jul 2000 17:17:37 -0400 (EDT) That one is a 93 minute delay (22:50:18 GMT - 21:17:37 GMT). I don't think this is poor SMTP connectivity at our end, but if no-one else is seeing these delays then obviously I will investigate that possibility. Otherwise: can anything be done to reduce the turnround delay? Or is it being imposed for our own good... ? :-] Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

3 3

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