toasters

toasters@lists.teaparty.net

13531 discussions

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

FC-AL: Onboard vs. PCI Card
by Shaun T. Erickson 13 Nov '99

13 Nov '99

Last summer, our F540 failed, and we moved our data to an F740. Two days later, the system crashed everytime it hit 51% of a disk-rebuild. Ultimately, it was determined that the onboard FC-AL controller was bad and the system board was replaced with one from a slightly older F740. We've been fine ever since. NetApp sent us a PCI FC-AL card, "just in case", but it's still in the box, unused. Having followed the "AW: 'Loop break detected' followed by failover" thread, and noted that people seem to be using the PCI adapters now, instead of the onboard adapters, and that apparently NetApp is shipping them with the PCI adapter standard now, I'm in a quandry. Should I proactively install the PCI adapter and switch to it, or should I leave well enough alone? Can someone at NetApp comment on this and give me some guidance? TIA, -ste -- Desk: (908) 582-7629 Pager: (800) 756-1133 Cell: (908) 672-6456

3 2

AW: 'Loop break detected' followed by failover
by bentele＠mtu-friedrichshafen.com 13 Nov '99

13 Nov '99

Hi Jay, we also had a ' isp2100_timeout]: Resetting ISP2100 in slot ..' a few weeks ago. F740 , DOT 5.2.3, FC-AL 18 GB, Gbit Card. !! Be careful !! Replacing motherboard and FC-Adapter-Card at last solved the problem, after we replaced all cables, all shelves of this loop, and about 3 disks. Mit freundlichen Grüßen Markus Bentele MTU Friedrichshafen GmbH * 07541-90-2654 * bentele(a)mtu-friedrichshafen.com > ---------- > Von: Jay Soffian[SMTP:jay@cimedia.com] > Gesendet: Mittwoch, 10. November 1999 08:07 > An: toasters(a)mathworks.com > Betreff: 'Loop break detected' followed by failover > > > I've opened a case with NOW on this. > > One of my filers (F740/512MB/28x9GB disks/DOT 5.2.3) tonight just did > this: > > Tue Nov 9 19:00:01 EST [subzero: statd]: 7:00pm up 44 days, 13:45 > 2570782327 NFS ops, 0 CIFS ops, 0 HTTP ops > Tue Nov 9 19:16:46 EST [subzero: isp2100_main]: Loop break detected on > ISP2100 in slot 1. > Tue Nov 9 19:16:50 EST [subzero: isp2100_timeout]: Resetting ISP2100 in > slot 1 > Tue Nov 9 19:19:14 EST [subzero/viking: cf_takeover]: relog syslog Tue > Nov 9 19:17:15 EST [subzero: isp2100_timeout]: Resetting ISP2100 in slot > 1 > Tue Nov 9 19:19:14 EST [subzero/viking: cf_takeover]: relog syslog Tue > Nov 9 19:17:27 EST [subzero: isp2100_timeout]: Resetting ISP2100 in slot > 1 > Tue Nov 9 19:19:15 EST [subzero/viking: asup_main]: Cluster Notification > mail sent > > No core dump, I found the filer at an 'ok' prompt. > > I rebooted the filer, did a cf giveback a few minutes later and all > appears fine now. > > Anything recommended besides checking that all cables are tight and > all drives are fully seated? > > I couldn't find any bugs relating to this on NOW (except a bug in the > Diagnostics not resetting the FC-AL loop properly when a loop break > occurs). I've heard rumors that some F740's were shipped with bad > on-board FC-AL controllers, but this F740 has been in operation for > over a year w/o any problems (it's only been clustered since June > though). > > Suggestions? > > j. >

5 5

RE: failing SCSI disks
by Priebe, Jason 13 Nov '99

13 Nov '99

I _would_ dump, then replace all the disks, but we can't buy pre-canistered 9GB SCSI disks anymore. So we're (on the advice of our sales rep) replacing the disks in the canisters ourselves. This is a laborious process, and I don't want to add to the downtime between dump and restore by trying to do it offline, so we're trying to do it one by one while the filer is online. Are we crazy? Jason Priebe WRAL OnLine http://www.wral-tv.com/ -----Original Message----- From: Gordon Keegan To: Priebe, Jason; 'toasters(a)mathworks.com' Sent: 11/12/99 12:01 PM Subject: Re: failing SCSI disks > * Priebe, Jason (priebe(a)wral-tv.com) done spit this rhetoric: > > 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. > > Not sure why you'd want to do that, as this would make only 4G of each of > the 9G drives useable... > What he said. When a smaller drive fails over to a larger spare, the larger spare is marked down as having the same capacity as the smaller. You would end up with a shelf of 9GB drives and the usable capacity of a shelf of 4GB drives. Better off dumping to tape and restoring to a shelf of empty 9GB's. -- Gordon Keegan, M10-10 Phone: (508) 261-4696 Motorola ING Fax: (508) 261-5757 20 Cabot Boulevard Mansfield, MA 02048 email: lgk011(a)dma.isg.mot.com

2 1

RE: Considering filers for major deployment....
by Sam Schorr 13 Nov '99

13 Nov '99

Alan, We have been using Snapmirror in production on 2 F740's and 2 F760's. We may be using it for different purpose than you might - its principally used to provide a RAID 1-ish protection for our on-line volumes, and a modified, limited read-only access for some of that data. The first thing to know is that Snapmirror uses Snapshot technology, so the first thing the filers do at the scheduled intervals is build a snapshot. It will always build a snapshot even if no data has changed, and it always copies a percentage of the volume being mirrored. This makes every-minute snapmirrors almost impractical for large volumes (ours are 200-250 gig). Are filers are "paired" using a directly connected gigE cross-connect (no switch or router). On a heavily loaded filer, snapmirrors can "timeout" as they try to build the snapshot - this is a known problem that netapp has a patch for that will be included in 5.3.4R1 (or so I'm told). We use a alternating, one hour window. That is, filer 1 in a pair runs at the 1 minute of the hour mark, while the other runs at the 30 minute of the hour mark. If you are snapping to a read-only filer, that has no other use (except for root), you get better results. Have fun! -----Original Message----- From: Mike Federwisch [mailto:mikef@netapp.com] Sent: Friday, November 12, 1999 3:44 PM To: Alan R. White Cc: toasters(a)mathworks.com Subject: Re: Considering filers for major deployment.... > 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? This one I can answer. Keep in mind that SnapMirror is not targeted to be a "almost real-time" remote replica. Its performance depends greatly on network, load, filesystem size etc. I wouldn't expect it to be a real-time style replica. If the networks are up to it you can get 24M/sec over the wire. Snapshots are created for each transfer which also take time. So figure out how much data changes per minute how fast your networks are and how much load you are planning on and you start to see how fast the updates can happen. I have seen situations where a per minute schedule can be achieved but I would lean more towards every 15 minutes or so but really it depends on your situation. I think it is a great product (I am biased) but I want to make sure your expectations are set correctly. Mike Federwisch Network Appliance

1 0

RE: Considering filers for major deployment....
by Benn, Paul 13 Nov '99

13 Nov '99

Hi Al, There's a simplified description of SnapShots (with pretty pictures) in my NT backup paper: http://www.netapp.com/tech_library/3052.html A more detailed take on SnapShots as well as SnapRestore and SnapMirror can be found here: http://www.netapp.com/tech_library/3043.html As for comparing a filer to brands X and Y (assuming you can get eval units from X and Y), I would suggest doing some performance tests as well as manageability tests using standard NT tools. Set file permissions, create user groups on the filer, create shares etc.. If you install the SecureShare Access utility, try setting UNIX permissions from NT (really cool). If your intent is to use the multiprotocol (CIFS and NFS) functionality, I'd also recommend that you test file locking between CIFS and NFS clients. Regards, Paul Benn -----Original Message----- From: Alan R. White [mailto:arw@tipper.demon.co.uk] Sent: Friday, November 12, 1999 3:16 PM To: toasters(a)mathworks.com Subject: Considering filers for major deployment.... 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

1 0

Re: failing SCSI disks
by Luke Mewburn 12 Nov '99

12 Nov '99

"Priebe, Jason" writes: > 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 did a similar thing a while ago to `migrate' disks in a volume to a different physical tray (I wanted to decommission a tray on an F330 to redeploy). To get the `failed' disks recognised by the filer again all I did was use the appropriate command on the boot floppies to zero the disk. I can't recall exactly, but I believe it's `disk_erase_label'. That command is available in the `rc_toggle_basic' mode of the filer. Make sure you use it on the right disk! NOTE: if you toast your data I ain't responsible! > 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? Yes, you should be able to. The `failed' state is just a flag in the label.

1 0

Re: Fast ENet cards for F330 and F540
by Luke Mewburn 12 Nov '99

12 Nov '99

"Walsh, Warren (MN65)" writes: > We've got two toasters, a F330 and F540. They're currently networked with > FDDI, but we would like to migrate to 100BaseT. NetApp has EOL'd these > models, even thought they're three years old, and does not sell these parts. > Anyone have suggestions for finding an alternate vendor for NetApp NICs? Or > a recommendation for a used/surplus dealer? How many 100Mb connections do you need per filer? The F330 has on-board 100Mb networking, although it's a different connector to the 10Mb network.

1 0

Two volumes with same name, DOT 5.2.1, how do I fix?
by John Stoffel 12 Nov '99

12 Nov '99

Hi guys, We're running DataOnTap 5.2.1 on a bunch of F330s. One of them had a disk failure this weekend, and since I was in for a power shutdown, I figured I'd just swap in a spare disk from a returned filer (upgrade to an F740). The problem is the before the old F330 was returned, we never did any of the disk commands to make all the disks into spares. We just copied the data off and shutdown the system. So I took one of these disks from the old Filer and did the usual disk swap, disk swap procedure to put it into the Filer with the failed disk. And now comes the problem. The Filer sees the new disk and scans it in, but hey! It's got volume info on it, and it won't initialize the disk and just use it on the new filer. Sigh... I've tried using the command 'disk fail 8a.4' but it won't let me because it's part of a volume. So I look at the volume status and I get this: swtoast> vol status Volume State Status Options vol0 online normal root vol0 offline foreign partial Yup, *two* volumes, both named 'vol0' and I can't get rid of the foreign one. If I just do 'vol status vol0' I get the online volume listed. What I want to do is just a volume destroy, or a disk initialize without any questions asked. But I can't figure out how to do this. Any hints? I do have a call into NetApp, but I've been on hold for about 15 minutes already... Thanks, John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel(a)lucent.com - http://www.lucent.com - 978-952-7548 john.stoffel(a)ascend.com - http://www.ascend.com

4 6

5.3.4 command-line history
by Brian Tao 12 Nov '99

12 Nov '99

Yay! > Data ONTAP 5.3.4 provides the following improvements to make entering > filer commands easier. > > History mechanism: You can scroll through recently entered commands > using the following methods: > > * Use the UP and DOWN arrow keys (cursor keys). > * Use Ctrl-P to scroll up and Ctrl-N to scroll down. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

2 2

RE: Two files with same name under NFS
by Rudie, Tony 11 Nov '99

11 Nov '99

You can cause this to happen if you mv (and perhaps cp) a file from a snapshot back into the main filesystem, if the file already exists in the main filesystem. the approved method is to remove the one in the main filesystem first. I'm a sissy, so I prefer moving the original to some other name, then copying in the one from snapshot, then removing the renamed original. -----Original Message----- From: Stephen C. Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Thursday, November 11, 1999 1:49 PM To: toasters(a)mathworks.com Subject: Two files with same name under NFS We are running ONTAP 5.2.3D1 in a mixed CIFS and NFS environment. Recently we encountered a directory that had two different files with the same name under NFS. This was reported by ls -ali | grep NEW 1176207 -rwxr-xr-x 1 1224 1224 674 Nov 10 10:32 NEW2.GIF 3907524 -rwxr-xr-x 1 1224 1224 674 Nov 10 10:32 NEW2.GIF Yes, we checked very carefully and there are no spaces or other unprintable characters in the names. Not trusting "ls" I even wrote a little perl script that calls readdir to print out the filenames and they are indeed identical. Actually, this ls output is erroneous because the two files have different permissions and mod time. Still, this does show the different inode numbers, indicating two distinct files. From W98 you can see these are two different files. One is named NEW2.GIF and the other is named NEW2~0.GIF. And the mod times are indeed different. So I conclude that we have a filename mapping problem where two different files map to the same NFS name. Is this a normal situation that should be expected periodically, or should this "never happen"? We know that under NFS you can create two files with the same spelling but different capitalization, but these are not allowed under CIFS. So when a NFS dir containing such conflicts gets converted to CIFS, the filenames are "massaged" by having ~number appear in the CIFS name. However, we couldn't come up with a repeat-by where we could create two files under CIFS with the same NFS name. Anyone else figure out how to do it? Also, once you have a situation like the above, it seems like it's a toss up as to which of the two files you see under NFS. Running ls -li NEW2.GIF on one NFS client showed one of the inums while running the same command on another NFS client showed the other. So this could cause confusion. Has anyone else experienced this? Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

Re: Strange routing problem
by Michael Salmon 11 Nov '99

11 Nov '99

+----- On Tue, 09 Nov 1999 16:39:52 PST, "Bruce Sterling Woodcock" writes: | > On Tue, 9 Nov 1999, Eyal Traitel wrote: | > | > > I had something a little similar I suspect... | > > Try toggling your RIP by "routed off|on". | > > You should also check that your /etc/rc contains something like: | > > | > > route add default 223.21.95.254 1 | > | > route add net default 223.21.95.254 1 | > | > to be exact. Otherwise you're putting in a host route. | | Your default route SHOULD be a host route. To the IP address of the | router. No, it is exactly the opposite. A host route implies a netmask of all 1's i.e. 255.255.255.255 but the default route has a netmask of all 0's i.e. 0.0.0.0 as it has to match all addresses. /Michael

2 1

RE: CIFS UMASK
by Muhlestein, Mark 11 Nov '99

11 Nov '99

Take a look at the security FAQ. It has info on the default perms for the various security styles when created by the various clients. In particular, look at "What kind of default security is set on files created by CIFS clients?" http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/faq.shtm l#anchor1395706 <http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/faq.sht ml#anchor1395706> Mark Muhlestein -- mmm(a)netapp.com <mailto:mmm@netapp.com> -----Original Message----- From: Travis Zadikem [mailto:travis@aztek-eng.com] Sent: Thursday, November 11, 1999 7:42 AM To: toasters(a)mathworks.com Subject: CIFS UMASK I as wondering if anyone knew of a way to set the default umask for somebody connecting via cifs. I do not want to use NFS and was not sure if this was possible or not. -- Travis A. Zadikem Senior Network Engineer PH: (303)-415-6175 Fax: (303)-786-9190 A mind is like a garden it only grows when fed and watered correctly.

1 0

solaris tuning (forked from 'Failure of rm -rf')
by Nick Christenson 11 Nov '99

11 Nov '99

> On Tue, 9 Nov 1999, Aimee Schmidt wrote: > > > Try installing the appropriate Solaris patches and tune NFS/DNLC > > parameters. This will improve performance by an order of magnitude or > > so. Whether/how much these patches help depends a great deal on the specifics of your situation. Nonetheless, these are probably good things. I wish Sun would let us know exactly how these patches implement their fix. > > Patches: > > 5.6 sparc - 105720-08 > > 5.6 i386 - 105721-08 > > 5.7 sparc - 106541-06 > > 5.7 i386 - 106542-06 > > > > Tunings (for /etc/system): > > set nfs:nfs_nra = 10 > > set nfs:nfs3_nra = 10 > > set nfs:nfs_max_threads = 24 > > set nfs:nfs3_max_threads = 24 > > set ncsize=8192 > > Aimee Some of these values are very different from what I've found to be effective on high volume mail systems. I'm not at all sure that ncsize needs to be set this low if the above patches actually fix bug "4212925 NFS client unlink operation slow" effectively, but again, since I don't know what the actual fix introduced was, it's hard to tell. > Does netapp have a white paper discussing suggested solaris > tuning parameters with some explanation on why the values were picked? Not that I know of. The "correct" numbers are application, machine, RAM, and implementation specific, so I doubt they could provide something simple that improved everyone's situation. > My department recently put a 740 in production as a mail spool with > a mid of solaris 7 and solaris 8(beta) hosts. I got a list of parameters > from another netapp engineer through a salesperson but was reluctant to > change the value of nfs:nfs_nra to 24 for example. For mail systems with small mailboxes I would expect that "10" might be higher than optimal. If you message store is one file per message and most messages are small, I would actually expect performance to be marginally worse with nfs_nra = 10 than with a lower value. I'd hesitate to speculate on what would be optimal without knowing the specific characteristics of a particular situation. > The default value for > this appears to be 524288! This would be several Gigabytes in size. In some situations, automatically loading in the whole file might be a good thing. In some situations, especially where the client connection was very slow, it might read the whole file into memory, but be so slow about sending the connection down to, say, a POP client that LRU caused some of this info to be flushed from the buffer cache before it got transmitted, in which case it would have to be read again, which would be a waste. > Since there are other applications that > suggest tuning these parameters, and Sun asks us to change them from time > to time, it is helpful to know 'why' we set the values. Certainly, it is important to understand what each of these parameters controls. > If the real answer is "we just iterated through lots of different > numbers and these are the ones that provided the best performance mix", > thats OK.. In most cases, this is probably the case. Note, though, that if your servers are memory poor the same parameters that work best on a similar machine with memory to spare are likely to be sub-optimal, for example. > FYI, here is the list of things we got from the salesperson: > ---- > set npty = 1024 > set nfs:nfs_nra = 10 > set nfs:nfs3_nra = 10 > set nfs:nfs_max_threads = 24 > set nfs:nfs3_max_threads = 24 On really busy mail servers with much memory, my opinion is that nfs_max_threads can be set much higher than this. I believe that one thread per concurrent process accessing data over NFS is not unreasonable as a rule of thumb, as long as the box doesn't start thrashing as a consequence. > set maxusers = 256 Depends on your box and how much RAM you use. For E250, E450, E3500, and larger servers, boosting this to 2048 is not unreasonable if you have RAM to burn in order to gain performance. > set ncsize = 30000 If you don't have one of the patches listed above applied, this may be a little too high. With the patches installed, without knowing how the problem was fixed, it's hard to say whether this number is too high or not. > set doingcache=0 I don't know what this does. > ----- It's impossible to come up with a general set of kernel tuning parameters for Solaris clients doing email over NFS without more information. The nature of the message store is important. The load characteristics are important. What client machines are being used and how much RAM do they have? Is it worth consuming more memory, network, and filer I/O resources to reduce POP or IMAP connection latency? Is the system primarily a POP, file based, or IMAP server? There are a large number of variables that precludes a simple answer. In everyone's case, there's not much to do about it except to understand what the parameters do and to iterate on them until good things happen. In order to understand what they do, I recommend the 2nd edition of Adrian Cockroft's Solaris performance tuning book and the SMCC NFS Server Performance and Tuning Guide from Sun. For the latter, it's a matter of time and effort. However, for those sites managing less than 100,000 mailboxes, the return on lots of careful tuning is probably small enough that it's not worth pursuing. One note of caution, Cockroft's book covers Solaris tuning up through about Solaris 2.5.1. While the descriptions are still valid, some of the math and parameters have changed. Not all the advice is good advice if you're running Solaris 2.6 or higher. The same would be true for older editions of the Tuning Guide. -- Nick Christenson npc(a)sendmail.com

2 1

CIFS UMASK
by Travis Zadikem 11 Nov '99

11 Nov '99

I as wondering if anyone knew of a way to set the default umask for somebody connecting via cifs. I do not want to use NFS and was not sure if this was possible or not. -- Travis A. Zadikem Senior Network Engineer PH: (303)-415-6175 Fax: (303)-786-9190 A mind is like a garden it only grows when fed and watered correctly.

1 0

Re: AW: 'Loop break detected' followed by failover
by alexei＠mindspring.net 11 Nov '99

11 Nov '99

bentele(a)mtu-friedrichshafen.com writes: > Replacing motherboard and FC-Adapter-Card at last solved the > problem, after we replaced all cables, all shelves of this loop, and about 3 > disks. One of my main complaints about the current fcal implementation for the filers is that there is no visual indicator of loop status. I know NetApp is working toward addressing this, but it would have been nice to have from the start. I wish fcal were more like token ring or fddi and that the loop were "self healing". When I had an LRC fail on an fcal shelf, there was no way of finding which LRC (used process of elimination) was the culprit, as the entire loop was offline, not just the failed shelf and those after it. Alex

5 4

Fast ENet cards for F330 and F540
by Walsh, Warren (MN65) 11 Nov '99

11 Nov '99

Hi All - We've got two toasters, a F330 and F540. They're currently networked with FDDI, but we would like to migrate to 100BaseT. NetApp has EOL'd these models, even thought they're three years old, and does not sell these parts. Anyone have suggestions for finding an alternate vendor for NetApp NICs? Or a recommendation for a used/surplus dealer? Thanks in advance. -warren Warren M. Walsh Honeywell Technology Center 612-951-7837 walsh_warren(a)htc.honeywell.com

1 0

Two files with same name under NFS
by Stephen C. Losen 11 Nov '99

11 Nov '99

We are running ONTAP 5.2.3D1 in a mixed CIFS and NFS environment. Recently we encountered a directory that had two different files with the same name under NFS. This was reported by ls -ali | grep NEW 1176207 -rwxr-xr-x 1 1224 1224 674 Nov 10 10:32 NEW2.GIF 3907524 -rwxr-xr-x 1 1224 1224 674 Nov 10 10:32 NEW2.GIF Yes, we checked very carefully and there are no spaces or other unprintable characters in the names. Not trusting "ls" I even wrote a little perl script that calls readdir to print out the filenames and they are indeed identical. Actually, this ls output is erroneous because the two files have different permissions and mod time. Still, this does show the different inode numbers, indicating two distinct files. From W98 you can see these are two different files. One is named NEW2.GIF and the other is named NEW2~0.GIF. And the mod times are indeed different. So I conclude that we have a filename mapping problem where two different files map to the same NFS name. Is this a normal situation that should be expected periodically, or should this "never happen"? We know that under NFS you can create two files with the same spelling but different capitalization, but these are not allowed under CIFS. So when a NFS dir containing such conflicts gets converted to CIFS, the filenames are "massaged" by having ~number appear in the CIFS name. However, we couldn't come up with a repeat-by where we could create two files under CIFS with the same NFS name. Anyone else figure out how to do it? Also, once you have a situation like the above, it seems like it's a toss up as to which of the two files you see under NFS. Running ls -li NEW2.GIF on one NFS client showed one of the inums while running the same command on another NFS client showed the other. So this could cause confusion. Has anyone else experienced this? Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

2 1

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