toasters

toasters@lists.teaparty.net

13515 discussions

Re: Netbackup error
by Steve Kappel 11 Jan '02

11 Jan '02

Hi Marcus, Have you contacted VERITAS Support? It looks like the client is not configured as an NDMP client. When you add a client to a class you tell NetBackup what kind of client it is. >From: "Bui, Marcus" <Marcus_Bui(a)aimfunds.com> >To: "'toasters(a)mathworks.com'" <toasters(a)mathworks.com> >Subject: Netbackup error >Date: Fri, 11 Jan 2002 09:33:37 -0600 > >All, > >I have Veritas Netbackup v3.4 running on Soloris. NDMP is "enable" on the >filer and the NDMP extension is installed on the Veritas master and media >servers. I was able to test the set_ndmp_attrib -verify from the Veritas >server. Netapp support verified the host and host.equiv entries is correct >on the filer. However, when the backup is started it will stay in the queue >forever. Once the job is killed this is what I got in the Veritas log. >This the last part of the log entries. > >... >... >16:53:52 [13931] <2> getsockconnected: Connect to ushoufile01 on port 712 >16:53:53 [13931] <2> getsockconnected: Connect to ushoufile01 on port 591 >16:53:54 [13931] <2> getsockconnected: Connect to ushoufile01 on port 711 >16:53:55 [13931] <2> getsockconnected: Connect to ushoufile01 on port 771 >16:53:56 [13931] <2> getsockconnected: Connect to ushoufile01 on port 728 >16:53:56 [13931] <16> getsockconnected: unable to connect() to ushoufile01, >Connection refused (146) >16:53:56 [13931] <16> bpcr_connect: Can't connect to client ushoufile01 >16:53:56 [13931] <16> log_in_errorDB: connection refused to host ushoufile01 >16:53:56 [13931] <16> log_in_errorDB: backup of client ushoufile01 exited >with status 150 (termination requested by administrator) > > >cheers, > >Marcus Bui >email: marcus_bui(a)aimfunds.com __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software (Engineering) steve(a)stevekappel.com (Personal)

1 0

Netbackup error
by Bui, Marcus 11 Jan '02

11 Jan '02

All, I have Veritas Netbackup v3.4 running on Soloris. NDMP is "enable" on the filer and the NDMP extension is installed on the Veritas master and media servers. I was able to test the set_ndmp_attrib -verify from the Veritas server. Netapp support verified the host and host.equiv entries is correct on the filer. However, when the backup is started it will stay in the queue forever. Once the job is killed this is what I got in the Veritas log. This the last part of the log entries. ... ... 16:53:52 [13931] <2> getsockconnected: Connect to ushoufile01 on port 712 16:53:53 [13931] <2> getsockconnected: Connect to ushoufile01 on port 591 16:53:54 [13931] <2> getsockconnected: Connect to ushoufile01 on port 711 16:53:55 [13931] <2> getsockconnected: Connect to ushoufile01 on port 771 16:53:56 [13931] <2> getsockconnected: Connect to ushoufile01 on port 728 16:53:56 [13931] <16> getsockconnected: unable to connect() to ushoufile01, Connection refused (146) 16:53:56 [13931] <16> bpcr_connect: Can't connect to client ushoufile01 16:53:56 [13931] <16> log_in_errorDB: connection refused to host ushoufile01 16:53:56 [13931] <16> log_in_errorDB: backup of client ushoufile01 exited with status 150 (termination requested by administrator) cheers, Marcus Bui email: marcus_bui(a)aimfunds.com

1 0

MIB variables and front panel LCD ops display
by Todd C. Merrill 10 Jan '02

10 Jan '02

What MIB variables and formula can be used to mimic the front panel LCD ops display? Summing: tnfsCalls - "The total number of NFS calls received, since since the last boot." trpcCalls - "The total number of RPC calls received, since the last boot." cifsTotalOps - "The number of CIFS operations done by the filer, since the last time the statistics were cleared." seems to be about right. But, is there a double-count here? NFS operates over RPC. 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 ---

2 1

(no subject)
by Uros Lampret 07 Jan '02

07 Jan '02

Has anybody tried using Filers on Macintosh OS 9.1 uros _____________________________ Uros Lampret Our Space Appliances d.o.o. internet: www.ourspace.si _____________________________

2 1

Solaris 8
by Uros Lampret 07 Jan '02

07 Jan '02

Hi! I was trying F840 on Solaris 8. Transfer rate with large files was great, but on smal files (2k) was not so good. I used default NFS mount options. Should I do some NFS optimization? Is there a white paper on it? Best regards, Uros _____________________________ Uros Lampret Our Space Appliances d.o.o. Tbilisijska 59 1000 Ljubljana - Slovenia tel. +386 1 2425 372 fax +386 1 2425 382 email: uros.lampret(a)ourspace.si internet: www.ourspace.si _____________________________

3 2

FC Drive failure recovery, continued...
by Dale Gass 07 Jan '02

07 Jan '02

Thanks once again to all the incredibly helpful folks... Here's my progress so far... I edited the disk label of the drive whose controller I replaced. It looks just like the others now. So I booted the system (readonly mode, thanks for that tip! :-), and the volume is actually online, and viewable, which is a major step forward. But I'm getting a lot of errors about inconsistent directory entries: Mon Jan 7 09:36:45 AST [/e3]: wafl_nfs_lookup: inconsistent directory entry {x20 0 8166461 156921645 16794490} <th.100x100.26.jpg> in {x20 0 15140401 133992804 16794490}. I have a couple of potential courses of action right now: - Copy all the data off that I can, regardless; this is obviously a good thing to do in any case. Unfortunately, the recursive copies I attempt seem to hang after a short while. Darn... - Take my drive-with-new-controller out of the set, and let the netapp attempt a rebuild onto a new drive, ignoring media errors on the second bad drive. I worry that this will create further corruption; but given the fact my current attempt has corruption, it might not be worse...? (And I might not be able to get back to where I currently am.) A cleaner (and safer) alternative might be to boot ignoring media errors, in read only mode, with my controller-replaced-drive out of the set. In read only mode, it shouldn't rebuild the set, and ignoring media errors, it might be able to access the data in degraded mode (or at least let me view what is available with that method...) - Let the netapp repair the inconsistencies; I'm not sure the best way to proceed on this one? I'm working on the tape-restore method in parallel, but anything we can get off via some creative tweaking, would be worth the try... I think I'll try the ignore-media-errors and read-only-mode thing next, to see what that view of the world is like. -dale

1 1

RE:
by Mitko Blazeski 07 Jan '02

07 Jan '02

Hi Uros I was running a F740 with 600 Mac clients on the newspaper I was working at. Sadly the filer dosen´t support Appletalk so we bought an program called Ethershare from Helios. It worked fine and the performance was stunning. The bad thing is that the software is rather expensive. Mitko Blazeski Professional Services CS Engineer ProAct Datasystem AB Djupdalsvägen 7, SE-191 24 Stockholm -----Original Message----- From: Uros Lampret [mailto:uros.lampret@ourspace.si] Sent: den 7 januari 2002 08:08 To: toasters(a)mathworks.com Subject: Has anybody tried using Filers on Macintosh OS 9.1 uros _____________________________ Uros Lampret Our Space Appliances d.o.o. internet: www.ourspace.si <http://www.ourspace.si> _____________________________

1 0

Bogus tape write rate from sysstat
by Chris Thompson 04 Jan '02

04 Jan '02

Has anyone else noticed this? Doing "systat -u 10" during a dump I see occasional obviously bogus values in the Tape Write column, e.g. CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 15% 12 7 5 6844 66 0 6438 >60 99% 3% T 44% 18% 3 1 2 8172 0 0 7651 >60 99% 0% - 51% 21% 43 597 617 7822 83 0 6645 >60 99% 3% T 51% 14% 12 3 8 5112 917 0 4511 >60 98% 13% T 32% 19% 12 8 3 8530 78 0 1844674406949348 >60 100% 6% T 61% 20% 7 4 4 8344 83 0 7490 >60 100% 12% T 64% 21% 6 2 10 8671 81 0 7858 >60 100% 7% T 65% 18% 8 4 14 7621 86 0 6896 >60 99% 5% T 57% I think that this has been happening only since I upgraded to 6.1.2. The observed frequency seems to be compatible with the hypothesis that the bogus values occur each time another 4GB has been written to the tape. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.

1 0

Update to a previous email
by Art Hebert 04 Jan '02

04 Jan '02

I posted this recently in response to somebody trying to sell a used netapp: Its more valuable to part it out than sell it. It cost more to have maintenance on it than to buy it. You can buy a terabyte of emc gear for $5K now. Our Netapp salesrep took offense as he thought I was bashing Netapp. I love Netapp, I've been using them for a long time. Its just that used netapps aren't worth it if you don't have a license, the parts are therefore worth more than the sum and at auction you can pick them and emc gear up really cheap. So do I am back in good graces with Netapp, pleaseeeeeee :-) Art Hebert Email: art(a)arzoon.com <mailto:art@arzoon.com> Arzoon IT Dept. Phone: 650 995-6125 Mobile: 650 444-8667

2 1

Replacing a FC Drive Controller Card...
by Dale Gass 04 Jan '02

04 Jan '02

Hey, got a couple of NetApp questions; they're a little low-level, and undoubtedly unsupported and warranty-voiding, etc., but any advice would be appreciated... (We don't have a support contract, due to the costs.) After moving a network appliance, it woke up kind of grumpy. One of the drives (Seagate Cheetah 18G FC-AL) didn't respond at all. Normally, when powering on a shelf, the green light typically goes off, blinks a bit, and then comes on solid. With this drive, the light just stays on solid, from the instant the switch is flipped on for the shelf. Pretty much non-responsive. So the unit attempts a rebuild. However, during the rebuild, unrecoverable media errors are encountered on another drive in the raid set. Sigh... "File system may be scrambled." So... With the netapp off, I try another drive in the non responsive shelf's slot. It's status light does the normal thing, so the shelf is okay, something is wrong with the drive or controller. Given the fact the light doesn't blink at all upon initialization, I suspect the controller. Since I had another spare drive, of exactly the same make/model, I tried swapping the controller card with the non-responsive unit. Doing so, then powering on the shelf, gives the normal status light sequence (blinking, then solid). A good sign so far. Then... Powering on the netapp: it says the raid set is still missing a drive, and shows the drive with the new controller, as "uninitialized", and assigns it to a hot spare, and then tries the rebuild again (which fails on the media errors on the other drive...) So. I'm guessing the NetApp uses the drive's serial # (which is on the controller card, not the drive, I presume) to keep track of the drive's function. I guess my three questions are as follows: 1. Is there any way to tell the NetApp that a drive's serial # has changed? (Where is this low-level raid configuration data stored? In NVRAM I assume? I looked around the files in /vol/vol0/etc, but nothing looked appropriate.) 2. Does the fact that the drive was flagged as a hot spare actually cause anything to be written to the drive, or is it just noted as such in the NetApp's configuration? (Also, since a rebuild was attempted, does that mean my data was overwritten? I guess since it was a rebuild, any data that was successfully rebuilt before the media errors, should be the same as was on the drive before, right? Or not...? The drive #was 26. There was another hot spare at #24; #26 is listed first in the host spare list on boot; would the lower-numbered or listed-first hot spare tend to be used? The filer didn't indicate *which* hot spare it was starting to use in the rebuild.) 3. Each time that the filer starts up, it claims to recover different blocks on the medium error, and claim they'll be reassigned. Is there any way to force the retries on this higher, so it will be more determined at recovery on the medium errors? Since different sectors are successfully read different times, one would think that if it did the reassignment each time, it would eventually recover the drive (maybe). Dual failures really suck on raid. I'm hoping that there's a way to bring this back to life. (We do have the data on tape; but due to a number of circumstances I won't go into here, restoring it would be *very* laborious, so I'm hoping for a bit more of a creative solution :-) Thanks, all... -dale

2 4

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