toasters

toasters@lists.teaparty.net

1 participants
13523 discussions

case #79131, Very Poor Backup performances: 1Gb/H with Veritas Netbackup through NFS
by Pierre Maubert 16 Nov '99

16 Nov '99

Hi, We have several F330 in TIF, 2 of them have an enourmous number of small files: over 3.5M for one single volume. We have increase the maxfiles value to 4328504. We have currently a significative degradation of backup performances on these 2 servers: backup are done at 1.5Gb, on both server, wheras we reach 5Gb/h for the 3 others. Servers are all running Dataontap5.2.3, and are all identical. F330, 128Mb Ram, 24*4Gb disks, I wonder what kind of fine tuning can be done to speed up the backup. -- Regards, Pierre . +------------------------------------------------------+ | Pierre Maubert, Sys_Admin Texas Instruments France | | email:p-maubert@ti.com Tel: +33 49322.2681 | | Fax: +33 49202.4669 Pager: 0606498982 | +------------------------------------------------------+

11 22

RE: FC-AL: Onboard vs. PCI Adapter Card
by Norman, Paul 16 Nov '99

16 Nov '99

> -----Original Message----- > From: Shaun T. Erickson [mailto:ste@research.bell-labs.com] > Sent: Monday, November 15, 1999 8:27 PM > To: Norman, Paul > Cc: toasters(a)mathworks.com > Subject: Re: FC-AL: Onboard vs. PCI Adapter Card > > > "Norman, Paul" wrote: > > > > Over the last couple days, there has been some discussion > about on-board FC-AL > > in our filers. This summer, NetApp started shipping > filers with an FC-AL > > adapter card rather than the on-board FC-AL to improve > reliability and > > performance. We did this because we found errors which, > though recoverable, > > potentially effect performance and loop stability. The > problem effected a very > > small fraction, just a few percent, of the installed base. > > Thank you for your reply. However, you didn't address the main > concern/perception of many folks here: that NetApp apparently shipped > many F700 series systems with onboard FC-AL controllers that had hard > failures shortly after being put into production, after which NetApp Perhaps I missed some e-mails, but I didn't see anyone suggesting that there were "many F700" filers that had "hard failures shortly after being put into production". As I said the number of filers with instability problems was quite small. We've shipped on the order of 5,000 F700 series filers, the vast majority of which run fine on on-board FC-AL. About one percent of these exhibited instability on the on-board FC-AL and not all of those the instant they were put into production. All that being said, as I look back on how we handled this problem I think NetApp should have been more aggressive in alerting the installed base. You can't be a chicken little crying the sky is falling every time you have a hiccup in the production line, but you also have to recognize when an issue is not just temporary problem. > apparently started sending out new filers with the PCI card > pre-installed, to be used in place of the onboard controller. That's > quite different from what you just described. > > Can you elaborate on and clarify this issue for us, please? I think I've been pretty clear, but please feel free to call me tomorrow if you want to discuss further. 408 822 6288 is my direct line. > > TIA, > -ste >

1 0

dump to Solaris tapehost w/ATL L200 fails
by Dennis Chandler 16 Nov '99

16 Nov '99

I am trying to use dump on a Network Appliance 230 (ontap 4.3.3) to dump to a remote tapehost. The remote tapehost is Solaris 2.5.1 with an ATL PowerStore L200 ( 5 tape loader). I realize that dump has reached the EOT. However, I'm having trouble getting dump to go to the next tape. If I list the /dev/nrst* files there is no /dev/nrst2. Here is the error message. Dennis Chandler > filer> dump 0ufb tapehost:/dev/nrst1 126 / > ... > DUMP: 66% done, finished in 2:23 > DUMP: Remote tape device write: expected 129024, got 0 > DUMP: write failed > DUMP: The ENTIRE dump is aborted. > DUMP: deleting "snapshot_for_dump.9" snapshot.

2 2

Cybernetics tape drive
by Frank Gilmurray 15 Nov '99

15 Nov '99

We just got a F720 filer and we looking into various backup solutions. We thinking about a Cybernetics 8050 with a 15 tape library. The 8050 is an AIT-2 drive with a 50GB native capacity. I'm soliciting comments (good and bad) about this tape system. If you have one of these tape systems, which backup program are you using with it? Thanks, Frank -- Frank Gilmurray Sr Systems Administrator SRI International tel: (650) 859-3246 333 Ravenswood Avenue fax: (650) 859-4812 Menlo Park, CA 94025 email: frank(a)erg.sri.com

1 0

PCI FC-AL
by Jay Soffian 15 Nov '99

15 Nov '99

So here's what I'm wondering. If NA suspects that there are problems with the onboard FC-AL in deployed filers, why hasn't NA issued a field notice to this effect? Why hasn't NA sent all of its support customers who have affected models the PCI FC-AL controller kits? It appears that NA is waiting till a customer has problems with the onboard FC-AL before shipping the PCI FC-AL kit. I know NA values its customers' data more than this. j. -- Jay Soffian <jay(a)cimedia.com> UNIX Systems Engineer Cox Interactive Media

2 1

failing SCSI disks
by Priebe, Jason 15 Nov '99

15 Nov '99

This is a really stupid question, but I can't find any answers to it in the documentation. We are going to replace the 4GB drives in our F210's shelf with 9GB drives by manually failing the 4GB disks one at a time. What concerns me is that the documentation mentions that failing a disk _permanently_ marks it as failed, so that it cannot be used in another filer. Am I totally naive, or is there some way that you can permanently mark a disk so that even if you reformat it, a filer still knows that the disk is failed? I don't intend to try to use the disks in another filer, but I am worried about rendering seven 4GB disks unusable with any SCSI system. Will I be able to use these disks with SCSI-equipped PCs? Jason Priebe WRAL OnLine http://www.wral-tv.com/

4 5

Considering filers for major deployment....
by Alan R. White 14 Nov '99

14 Nov '99

Hi All, I've got a toaster onsite ready to start evaluating. If everything works out OK there's terabytes of business for NetApp at our shop. I'm hoping the collective experience on the group can help us get up to speed with filers - the sales guys are really good about answering the questions but I suspect you're going to be a tad more impartial ;-) Hope you don't mind the newbie questions below - if you prefer mail me directly and I can summarise back to the list. The claims of simplicity, reliability, minimal downtime, performance for filing (compared to NT) and snapshots are what attracted me to look at the boxes - I haven't seen any horror stories in the archives - is this too good to be true? The FC-AL stuff recently looked a bit dodgey. How many folks actualy cluster their filers? Claims of 99.997% uptime without clustering sound, once again, too good. Is the clustering simple primary-failover or can we do n-way clusters with load sharing etc? Is the cluster setup really a one-command 15 minute job? User restore on their NT clients by mapping the snapshots looks a good idea. Is it usable in the real world? It would save us heaps of hassle with classic 'ask IT to do it' restores. Any good rule of thumb sizing advice for the amount of space to reserve for snapshots? Similarly for automated snapshot schemes, does anyone do multiple snapshots intra-day and maybe keep one for a longer period, e.g. keep a midnight snapshot for x days. Is SnapMirror up to the job of keeping an almost real-time remote replica, i.e. snap every minute if the networks up to it? Are there any operational issues around this stuff? Is anyone prepare to comment privately or otherwise on any recent comparisons they've done with Celera and Auspex? I understand the cost thing with EMC but loads of people seem to buy them still. This is not intended as flame bait for all the NetApp advocates. Any advice on what we should really include in our eval to really test the box out? ...or indeed comments in general that would be useful for us. TIA, Al

5 4

cf headache
by Jay Soffian 14 Nov '99

14 Nov '99

Well, adding the PCI FC-AL contollers that NetApp sent to replace the onboard FC-AL for our clustered F740 pair did _not_ go smoothly. This marks two times in a row now that I've attempted to use 'cf takeover' in order to prevent downtime and it has lead to downtime of over an hour. The previous time, we were bitten by the uptime bug. This time, who knows. When I tried to do a 'cf takeover' on filer A, for some reason, it decided to mark one of filer B's data disks as a hot-spare, and then it panic'ed: subzero> Sun Nov 14 02:56:35 EST [subzero: rc]: Cluster monitor: takeover initiated by operator Sun Nov 14 02:56:35 EST [subzero: cf_main]: Cluster monitor: UP --> TAKEOVER Sun Nov 14 02:56:35 EST [subzero: cf_takeover]: Cluster monitor: takeover started Sun Nov 14 02:56:48 EST [subzero: disk_admin]: Resetting all devices on ISP2100 in slot 1 Sun Nov 14 02:56:55 EST [subzero: cf_takeover]: Marking disk 1.8 as a "hot spare" disk.Sun Nov 14 02:56:56 EST [subzero: raid_disk_admin]: One disk is missing from volume partner:cim0a, RAID group 1. A "hot spare" disk is available and the missing disk will be reconstructed on the spare disk. PANIC: wafl_check_vbns: vbn too big on Sun Nov 14 07:56:57 1999 Cluster monitor: panic during takeover Cluster monitor: takeover capability will be disabled on reboot subzero came back up okay. I hoped the other filer (viking) would come back up okay and begin a RAID reconstuct, but it was convinced the filesystem was hosed: Disk 0a.4 is reserved for "hot spare" Disk 0a.8 is reserved for "hot spare" Disk 0a.13 is reserved for "hot spare" 3 disks are reserved for "hot spare". 27 disks are owned by clustered failover partner. Sun Nov 14 08:03:13 GMT [rc]: A disk is missing from one or more RAID groups. System starting in degraded mode. disk: RAID label 1 and 2: magic/time/gen/shutdown fsid/rgid/rgdn/total 0a.0 : RAID/942566217/1881/0 20036d6/0/3/17/ RAID/942566217/1881/0 20036d6/0/3/17/ 0a.1 : RAID/942566217/1881/0 20036d6/0/4/17/ RAID/942566217/1881/0 20036d6/0/4/17/ 0a.2 : RAID/942566217/1881/0 20036d6/0/1/17/ RAID/942566217/1881/0 20036d6/0/1/17/ 0a.3 : RAID/942566217/1881/0 20036d6/1/3/17/ RAID/942566217/1881/0 20036d6/1/3/17/ 0a.4 : SPARE/0/0/0 ffffffff/-1/-1/1/ SPARE/0/0/0 ffffffff/-1/-1/1/ 0a.5 : RAID/942566217/1881/0 20036d6/0/0/17/ RAID/942566217/1881/0 20036d6/0/0/17/ 0a.6 : RAID/942566217/1881/0 20036d6/0/5/17/ RAID/942566217/1881/0 20036d6/0/5/17/ 0a.8 : SPARE/0/0/0 ffffffff/-1/-1/1/ SPARE/0/0/0 ffffffff/-1/-1/1/ 0a.9 : RAID/942566217/1881/0 20036d6/1/5/17/ RAID/942566217/1881/0 20036d6/1/5/17/ 0a.10 : RAID/942566217/1881/0 20036d6/1/2/17/ RAID/942566217/1881/0 20036d6/1/2/17/ 0a.11 : RAID/942566217/1881/0 20036d6/2/4/17/ RAID/942566217/1881/0 20036d6/2/4/17/ 0a.12 : RAID/942566217/1881/0 20036d6/2/2/17/ RAID/942566217/1881/0 20036d6/2/2/17/ 0a.13 : SPARE/0/0/0 ffffffff/-1/-1/1/ SPARE/0/0/0 ffffffff/-1/-1/1/ 0a.14 : RAID/942566217/1881/0 20036d6/0/2/17/ RAID/942566217/1881/0 20036d6/0/2/17/ 0a.16 : RAID/942566217/1881/0 20036d6/2/3/17/ RAID/942566217/1881/0 20036d6/2/3/17/ 0a.17 : RAID/942566217/1881/0 20036d6/2/0/17/ RAID/942566217/1881/0 20036d6/2/0/17/ 0a.18 : RAID/942566217/1881/0 20036d6/2/1/17/ RAID/942566217/1881/0 20036d6/2/1/17/ 0a.19 : RAID/942566216/1659/0 36d6/0/0/2/P RAID/942566216/1659/0 36d6/0/0/2/P 0a.20 : RAID/942566216/1659/0 36d6/0/1/2/S RAID/942566216/1659/0 36d6/0/1/2/S 0a.21 : RAID/942566217/1881/0 20036d6/1/1/17/ RAID/942566217/1881/0 20036d6/1/1/17/ 0a.22 : RAID/942566217/1881/0 20036d6/1/0/17/ RAID/942566217/1881/0 20036d6/1/0/17/ 1.0 : SPARE/0/0/0 ffffffff/-1/-1/1/ SPARE/0/0/0 ffffffff/-1/-1/1/ 1.2 : RAID/942566451/3443/0 10022f5/0/4/6/ RAID/942566451/3443/0 10022f5/0/4/6/ 1.1 : RAID/942566451/3894/0 20022f5/0/1/18/ RAID/942566451/3894/0 20022f5/0/1/18/ 1.4 : RAID/942566451/3894/0 20022f5/2/4/18/ RAID/942566451/3894/0 20022f5/2/4/18/ 1.5 : RAID/942566451/3894/0 20022f5/2/1/18/ RAID/942566451/3894/0 20022f5/2/1/18/ 1.3 : RAID/942566451/3894/0 20022f5/2/5/18/ RAID/942566451/3894/0 20022f5/2/5/18/ 1.9 : RAID/942566451/3443/0 10022f5/0/0/6/ RAID/942566451/3443/0 10022f5/0/0/6/ 1.8 : RAID/942566451/3443/0 10022f5/0/5/6/ RAID/942566451/3443/0 10022f5/0/5/6/ 1.6 : RAID/942566451/3894/0 20022f5/0/3/18/ RAID/942566451/3894/0 20022f5/0/3/18/ 1.11 : RAID/942566451/3894/0 20022f5/1/5/18/ RAID/942566451/3894/0 20022f5/1/5/18/ 1.12 : RAID/942566451/3894/0 20022f5/2/0/18/ RAID/942566451/3894/0 20022f5/2/0/18/ 1.14 : RAID/942566451/3894/0 20022f5/1/4/18/ RAID/942566451/3894/0 20022f5/1/4/18/ 1.16 : RAID/942566451/3894/0 20022f5/2/2/18/ RAID/942566451/3894/0 20022f5/2/2/18/ 1.17 : RAID/942566451/3443/0 10022f5/0/2/6/ RAID/942566451/3443/0 10022f5/0/2/6/ 1.18 : RAID/942566451/3443/0 10022f5/0/3/6/ RAID/942566451/3443/0 10022f5/0/3/6/ 1.19 : RAID/942566451/3769/0 22f5/0/0/2/P RAID/942566451/3769/0 22f5/0/0/2/P 1.20 : RAID/942566451/3769/0 22f5/0/1/2/S RAID/942566451/3769/0 22f5/0/1/2/S 1.21 : RAID/942566451/3443/0 10022f5/0/1/6/ RAID/942566451/3443/0 10022f5/0/1/6/ 1.22 : RAID/942566451/3894/0 20022f5/0/4/18/ RAID/942566451/3894/0 20022f5/0/4/18/ 1.24 : RAID/942566451/3894/0 20022f5/0/0/18/ RAID/942566451/3894/0 20022f5/0/0/18/ 1.25 : RAID/942566451/3894/0 20022f5/0/5/18/ RAID/942566451/3894/0 20022f5/0/5/18/ 1.26 : RAID/942566451/3894/0 20022f5/0/2/18/ RAID/942566451/3894/0 20022f5/0/2/18/ 1.28 : RAID/942566451/3894/0 20022f5/1/2/18/ RAID/942566451/3894/0 20022f5/1/2/18/ 1.27 : RAID/942566451/3894/0 20022f5/1/1/18/ RAID/942566451/3894/0 20022f5/1/1/18/ 1.29 : RAID/942566451/3894/0 20022f5/1/0/18/ RAID/942566451/3894/0 20022f5/1/0/18/ 1.30 : RAID/942566451/3894/0 20022f5/1/3/18/ RAID/942566451/3894/0 20022f5/1/3/18/ 1.10 : RAID/942566451/3894/0 20022f5/2/3/18/ RAID/942566451/3894/0 20022f5/2/3/18/ Unclean shutdown in degraded mode without NVRAM protection. Filesystem may be scrambled. Please contact Network Appliance Customer Support. (You must boot from floppy to take any further action) Joy. I presume this is because subzero panic'd. Had subzero not panic'd I'm guessing subzero would have begun a reconstruct for viking's disks (after it blew-away that data disk for whatever reason). Anyway, at this point, we decided to put in the PCI FC-AL hoping the filer would notice the disks on reboot (I hadn't yet diagnosed why a data disk was missing). No go. So we ran wackz. 20 minutes later wackz found no problems. Rebooted the filer and it came up and began a reconstruct. It chose one of its other spares, not the former data-disk spare to reconstruct onto. (During reconstruct, the filer 'recovered error' twice on another disk in the same RAID group, glad it didn't decide to throw that disk or I guess I would have been trying to figure how to get that hot-spare-used-to-be-a-data-disk back as a data disk.) I didn't want to risk another 'cf takeover' (esp during a reconstuct), so I just halted the other filer to add its PCI FC-AL. No incident there. Case has been opened with Netapp. This is getting really old. Oh yeah, 5.2.3 on both filers. Both filers have succefully done a 'cf takeover' during the past (during testing a few different times). Apparently, 'cf takeover' only fails when you actually _need_ it. On the bright side, NetApp customer support was pretty helpful. It was a multi-national effort (I was coordinating from Atlanta, the person performing the maintenence at our co-lo was in Sunnyvale and the NA customer support person (Renee) was in the Netherlands). j.

1 0

FC-AL: Onboard vs. PCI Card - performance
by Jay Soffian 14 Nov '99

14 Nov '99

The replacement FC-AL PCI controller I'm about to add is a 32-bit card (as is the cluster FC-AL controller already installed). The on-board FC-AL controller is 64-bit. Are there any performance differences between the two? Geez, if this filer ever has to run in failover mode, it will have active FC-AL contollers in slots 1,2, active GigE in slots 6,7, active cluster interconnect in slot 8. Busy backplane. Also, suddenly, my F740s are down to one free slot. Hrmph. j.

1 0

Single-mode vif failover reaction time
by Brian Tao 13 Nov '99

13 Nov '99

I started playing with single-mode VIF's on 5.3.4 today (F740, QFE NIC installed in slot 3). I have e3a connected to one Cisco 2924XL and e3b connected to a different 2924XL. Both switches are bridged together so that it essentially looks like a 48-port switch to the hosts connected to it. adm-na5> vif create single na5-vif1 e3a e3b adm-na5> vif favor e3b adm-na5> ifconfig na5-vif1 10.35.8.21 netmask 255.255.255.128 up I created a single-mode trunk with e3a and e3b, favouring e3b (no particular reason, other than to see that the filer won't assume the first interface in the "vif" command will be favoured), ifconfigged it, and verified that it was pingable. I started up a few scripts to record any NFS outages while I played with the failover. Link failure was simulated by unplugging the filer's cable from both the switch end and the filer end. "vif status" and "vif stat" both verified that all traffic was passing over the e3b link exclusively. I yanked out the e3b cable from the switch: > Virtual interface (trunk) na5-vif1 > e3a e3b > Pkts In Pkts Out Pkts In Pkts Out > 294767 13473 856994 38899 > 0 0 3095 141 > 0 0 3236 149 > 0 0 2403 104 > Thu Nov 11 23:34:20 GMT [de2]: de_main: e3b : Link down. Check cable. > 2527 122 0 0 > 3737 162 0 0 > 3209 141 0 0 > 3551 156 0 0 Instantaneous failover! I was worried that the Catalysts would spend 20 or 30 seconds doing loop detection, but nothing even blinks at the loss of one of the links. Hurrah. :) But then I plug e3b back in, give it time to settle (at this point, the switch does do a recalc), and then unplug e3a to force a "give back" to e3b, I observe about 15 seconds where no traffic is passed over either link: > Virtual interface (trunk) na5-vif1 > e3a e3b > Pkts In Pkts Out Pkts In Pkts Out > 569739 25859 873099 39627 > 5558 239 0 0 > 3137 147 0 0 > 3550 162 0 0 > Thu Nov 11 23:35:40 GMT [de1]: de_main: e3a : Link down. Check cable. > 0 0 0 0 > 0 0 2 0 > 0 0 0 0 > 0 0 0 0 > 0 0 1 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 0 0 > 0 0 2 2 > 0 0 1 1 > 0 0 1 1 > 0 0 1 1 > 0 0 2347 103 > 0 0 1 1 > 0 0 1 1 > 0 0 1450 64 > 0 0 4857 206 > 0 0 3807 163 > 0 0 3983 174 NFS clients definitely notice that. Is this normal for the Netapp, or should I be looking at my switch configuration? Also, is there a way to force the Netapp to automatically switch back to the favoured link when it comes back up (perhaps after a short timeout, in case the interface is bouncing up and down)? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

2 2

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