toasters

toasters@lists.teaparty.net

13531 discussions

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

cannot lockf
by Jim Harm 10 Jul '00

10 Jul '00

I know there was discussion on this before, but I don't recall any resolution. It started with the binmail program could not NFS lock the file. I have run the lockdump -h command and found the processes and the files. The processes are no longer running on the host. The file no longer exists.(I removed it) The locks are still on the filer. How can I get rid of them? and(anyone) Why does the NetApp box keep the lock for processes/files that don't exist? }}}===============>> LLNL James E. Harm (Jim); jharm(a)llnl.gov System Administrator Compaq Clusters (925) 422-4018 Page: 423-7705x57152

2 2

RE: volume/shelf containment
by abond＠netapp.com 10 Jul '00

10 Jul '00

I'd like to put the cat among the pigeons here(!), and ask why you feel it is necessary or desirable to "contain each volume to a shelf of its own". The same situation you have seen here is likely to occur again if another disk fails (it will, eventually). One reason to buy a filer is to minimise administration and maximise uptime, and this process will increase administration as well as introduce unnecessary downtime. One possible explanation is that you need to move some disks later to another filer - in which case identify at that time which disks comprise the volume you wish to move, and then simply move those. As mentioned by others, if you halt the filer, you can move the disks around with no fear whatsoever of confusing the filer - the disk's identity is not related to the slot in which it finds itself, rather to the label on the disk. It is also desirable to minimise the number of "disk fail" operations, following the maxim of "if it ain't broke, don't fix it" :-) Regards, Andrew > -----Original Message----- > From: Fox, Adam > Sent: 10 July 2000 15:55 > To: toasters(a)mathworks.com > Subject: RE: volume/shelf containment > > > There is a simplier way to do this, but it involves halting > the filer. > > You could simply, halt the filer, place the disks where > you want them, then reboot. > > Sorry I didn't mention this obvious way before, but I > tend to think in terms of no downtime. > > -- Adam Fox > NetApp Professional Services, NC > adamfox(a)netapp.com > > > > > -----Original Message----- > > From: Fox, Adam > > Sent: Monday, July 10, 2000 10:38 AM > > To: makin(a)dnrc.bell-labs.com; toasters(a)mathworks.com > > Subject: RE: volume/shelf containment > > > > > > > > > > > -----Original Message----- > > > From: Bhavnesh Makin [mailto:makin@dnrc.bell-labs.com] > > > Sent: Monday, July 10, 2000 10:04 AM > > > To: toasters(a)mathworks.com > > > Subject: volume/shelf containment > > > > > > > > > We have a F740 filer with two 18 gig shelves. Each shelf is > > > dedicated to > > > a volume.We have reserved disk on each shelf as a > hotspare for that > > > particular volume. So in total we have two hot spares. > > > > > > Last week one of the disks failed on the first volume and > > failed disk > > > was recontructed on the spare which was physically > present on second > > > shelf. So we ended up with the volume which transgresses over to > > > another shelf. Our goal was to contain each volume to a > shelf of its > > > own. > > > > > > First,is there a way to contain the volumes with hot > > spares? Secondly > > > how do I make the first volume give up the disk on second > shelf and > > > recontruct it on spare which is physically present on first shelf. > > > > As far as I understand it, spares are global to the filer. > The filer > > will pick the smallest spare disk that will fit. So unless you have > > different sized disks on different volumes, you can't make a > > filer pick > > one disk over another. > > > > As far as fixing your current situation. Config your system > > now so that > > it only have 1 spare (it may be that way anyway now), then > > fail over the > > spare in the 2nd shelf which is now a data drive for the > volume on the > > first shelf. In my opinion, the best way to do this is to > > run the 'disk fail' > > command rather than pull the drive. I think it's cleaner > > since you won't > > have to cause your lop to reset. Then you will force your > > volume to rebuild > > on the only spare in the system, which not so coincidentally > > is the one you > > want. > > > > Hope this helps. > > > > -- Adam Fox > > NetApp Professional Services, NC > > adamfox(a)netapp.com > > >

3 2

RE: volume/shelf containment
by Adam.Fox＠netapp.com 10 Jul '00

10 Jul '00

I 'm new at this NetApp stuff so you may want to get a second opinion but if you pull the rebuilt spare then the first volume will rebuild it on the other spare. Plug it back in and it is now a dirty spare. Chuck This is true, but if you KNOW the disk is good, you can run the disk_zero command (I think you have to rc_toggle_basic first). Then pop the disk out and put it back in, and *poof*, it's a regular spare again! Little tricks that may help you! -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com

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