toasters July 1999

toasters@lists.teaparty.net

90 participants
108 discussions

Sun Client Maximum Throughputs
by beepy＠netapp.com 05 Jan '00

05 Jan '00

Do any of our customers out there have some measurements of Sun client throughput? I thought I could use a 2 x 400MHz Ultra Enterprise E250 with a new Sun GbE card in it as a killer client, and I find that with V3 32KB UDP packets, the sucker rolls over at ~30 MB/s with 2 CPUs pinned at 99% in system time. This *sucks*. In an experimental filer setup reading from memory (all cached data) the F760 CPU is at 20%. I am totally client bound. Has anyone sized Sun clients out there? Are the PCI clients dogs? Is the new GbE card from Sun a loser? Should I go grab a new Alteon card for the Sun? What is your killer high performance client? It seems a function of the Sun E250 - 100BaseT seems to scale only to 30 MB/s before running out of CPU... Broken-hearted in Amsterdam, beepy

9 13

Wincenter Pro, excel 97 and netapp problem
by Krzysztof Miller 25 Nov '99

25 Nov '99

Hi, I am new on this list. Let me introduce myself - my name is Krzysztof Miller, I work for Lucent Technologies CIO dept, in Poland. We have F520 running 5.1.2 . Did anybody had problems with Wincenter Pro (or Cytrix Winframe) and NetApp ? We have following problem - when excel 97 session is open when you log off from wincenter, it deletes file, which is opened. NCD support suggest to upgrade system to 4.3.4D9, but I have 5.1.2 regards -- _____________________________________________________________ Krzysztof M. Miller, CIO Poland email : tytus(a)lucent.com phone : +48 52 3491845 fax : +48 52 3463033 mobile: +48 601 358032 _____________________________________________________________

3 2

Re: show_therm
by sirbruce＠ix.netcom.com 01 Aug '99

01 Aug '99

On 07/30/99 21:27:32 you wrote: >Netapp - why do you do these things >to me?!?!?!?!? > >Graham Graham - why would you rely on undocumented and unsupported commands and risk disappointing your management?!?!? Bruce

6 5

Re:ISP_2100: cmd opcode 0x28, retry count 0: command timeout, aborting request error
by raster＠netapp.com 01 Aug '99

01 Aug '99

>Can anyone shed some light on the error below? It looks like it is just a >media error which was recovered from, but I wanted verification. > Thank you, > Mike > > >Wed May 12 00:13:03 EDT [isp2100_timeout]: 8.45 (cmd opcode 0x28, retry >count 0): command timeout, aborting request >Wed May 12 00:13:03 EDT [isp2100_timeout]: isp2100_reset_device: device 8.45 >(1.45) Hi Mike, The above message sequence is a symptom of SCSI command timeout. As part of timeout recovery, the device in question is reset and all pending commands are reissued. Hope this helps. -- --------------------------------------------------------------------------- Radek Aster [ raster_at_netapp_dot_com ] | "I bike, therefore I am" http://www.nowhere.net/~raster/ | - Rene' DesBiketes ---------------------------------------------------------------------------

6 11

Re: CIFS Remote Backup Options
by Matt Day 31 Jul '99

31 Jul '99

Garrett Burke <Garrett.Burke(a)msc.ie> wrote: >I currently use ARCServe 6.5 for backing up a F230,256MB RAM, 4MB NVRAM on >100BaseT full duplex, Extreme S48 switch, running OnTap 5.2.1 Issues that >have bitten us in the past are: > >a) It's slow. Backing up 24GB from the F230 using ARCServe 6.5 build 622 on >a DELL PowerEdge 1300 PIII 450 with 256MB Ram and 15 slot Compaq DLT70 >library (which is actually has a HP C5173-7000) I got 92.43 MB/min last >night which is about average. Note that we have lots of small files (source >code) The 24GB is made up of 315,913 files and 29,525 directories on a >single volume so you may see better performance or worse depending on your >mix. > >[..] > >c) oplocks. This has caused us numerous problems. We now run the backups >with oplocks turned off, as there some sort of interaction between ARCServe >and the oplock code (we tried a few D releases but never got around it) >which means that things run very, very slowly. Like, 2 days to run the >backup! Hi Garrett, There is an oplock bug in 5.2.1 (burt12483) that sometimes delays the delivery of oplock break messages -- I bet that's the performance problem you're hitting with oplocks enabled. The fix for this bug is available in 5.2.2P1 and 5.3. Have you tried either of those releases? Matt

2 1

show_therm
by Graham Knight 31 Jul '99

31 Jul '99

Well, i spent a goodly amount of time integrating the output of "show_therm" into our MRTG graphs, and did some bragging to management about how cool it was (and they agreed). Now, i load rev 5.2.3 of the OS and the command is *gone*!!!! Netapp - why do you do these things to me?!?!?!?!? Graham

1 0

RE: SnapMirror Very Slow
by Melvin, Grant 30 Jul '99

30 Jul '99

Hi, Just wanted to throw in that we discussed with David Midgett (while waiting for the next SnapMirror schedule to be triggered) how he was using SnapMirror. And heard (correct me if I'm wrong David) that his copy of data was being accessed by other clients in read-only fashion effectively balancing the client load across the CFO pair. So not only does David have a (local) disaster recovery copy of his data, but its also accessible (in read-only mode) at all times (after the baseline transfer has completed). Cheers, Grant -----Original Message----- From: alexei(a)mindspring.net [mailto:alexei@mindspring.net] Sent: Thursday, July 29, 1999 3:35 PM To: Sam Schorr Cc: toasters(a)mathworks.com Subject: Re: SnapMirror Very Slow Sam Schorr <sschorr(a)homestead.com> writes: > Actually, there is a very good reason to do both. Clustering only protects > filer head failures. If a volume on a filer loses 2 disks in 1 RAID group, > the volume built on that RAID group is useless and needs to be rebuilt upon > disk repair. So, by using SNAPMIRROR to "almost realtime" copy data to a > read-only volume on another filer, upon disk failure that volume can be made > "live" or the master volume. This is a strategy we are employing to fully > protect our users' data and insure the highest availability of that data. I am not arguing that doing both is not (potentially) good, but doing both on the same set of filers is troublesome. Individually, each solution addresses a set of problems, and each has its own set of problems. With CF (cluster failover), you get transparent (or close to) failover such that a client does not percieve a failure, just a pause. The cluster partner is then serving both sets of data (its own and that of its partner). If you do not size the filer correctly, you are going to be in trouble, especially if you loose a disk during failover. Snapshots are an additional overhead. With snapmirror, you have a copy of the data N minutes old (where N is a function based on the network latency, the size of the volume (clustermap overhead), size of the network pipe and ammount of deltas). In order to make that copy "live", you will need to update mount points across your clients in order to point at the now-read-write snapmirror volume on the other filer. So, doing snapmirror between cluster members is not a clear win. You are better off snapmirroring to a filer that is not part of the cluster. That way you can isolate your disaster backup copy from any potential problems the cluster might experience. Alex

2 1

RE: CIFS Remote Backup Options
by Garrett Burke 30 Jul '99

30 Jul '99

Hi Anissa, I currently use ARCServe 6.5 for backing up a F230,256MB RAM, 4MB NVRAM on 100BaseT full duplex, Extreme S48 switch, running OnTap 5.2.1 Issues that have bitten us in the past are: a) It's slow. Backing up 24GB from the F230 using ARCServe 6.5 build 622 on a DELL PowerEdge 1300 PIII 450 with 256MB Ram and 15 slot Compaq DLT70 library (which is actually has a HP C5173-7000) I got 92.43 MB/min last night which is about average. Note that we have lots of small files (source code) The 24GB is made up of 315,913 files and 29,525 directories on a single volume so you may see better performance or worse depending on your mix. b) careful of share permissions. Make sure when setting up the Job that the username and password entered in the security dialog can connect to the filer. We use the pre & post script option in ARCServe to create and share a snapshot (& turn oplocks off, see below), backup from the share and then unshare the snapshot. c) oplocks. This has caused us numerous problems. We now run the backups with oplocks turned off, as there some sort of interaction between ARCServe and the oplock code (we tried a few D releases but never got around it) which means that things run very, very slowly. Like, 2 days to run the backup! d) watch your network infrastructure. If you are dropping packets then you will see a major performance hit. Of course, the usual thing of ensuring that your duplex setting match on both filer and switch need to be taken care of. Note that the performance figures given at http://www.netapp.com/technology/level3/3052.html are for ARCServe IT 6.6, but I haven't heard of any other performance figures for 6.6 from filer users. Anyone out there using ARCServe IT 6.6 to backup a filer? Regards, GB > ---------- > From: Mohler, Anissa[SMTP:amohler@mail.bokf.com] > Sent: 29 July 1999 18:28 > To: 'toasters(a)mathworks.com' > Subject: CIFS Remote Backup Options > > I am working on design of a backup system for our F740 filer (100G usable) > in a CIFS environment. At this time we have no plans on directly attaching > a > tape backup device to the filer. Our current enterprise backup solution is > ARCserve 6.5 (on NT). > > I have the White Paper on NT Backups and am wondering what is actually in > use in the field. Are there any gotcha's I need to watch out for? Any best > practices out there? > > Thanks! > > Anissa Mohler > amohler(a)mail.bokf.com > BOKf Network Services Group >

1 0

Restore problems.Please help !!!!
by Richard Burton 30 Jul '99

30 Jul '99

Anyone has any insights as to what I am doing wrong?I am trying to restore a single file from a 5 tape dump. The tape inserted in the beginning is the correct tape (tape 5).Should I get any message from restore saying that it liked my tape 5 and would now need the next tape ? Because I inserted tape 4 after 5 and got Wrong volume 2.Can anyone explain why it does not say wrong volume 5 but says wrong volume 1. Moreover why does it crap out on me with the 'Tape Block size should be 10240, not 64512' message ? Any help is greatly appreciated.The dump command I used is : dump 0uf urst0a,urst0a,urst0a,urst0a,rst0a /vol/vol0 bean> restore xvfD rst0a /vol/vol0/test/restore /users/john/lib/hit.c RESTORE: Dump date: Mon Jul 28 15:46:35 PDT 1999 RESTORE: Dumped from: the epoch RESTORE: Level 0 dump of /vol/vol0/ on bean:/vol/vol0/../snapshot_for_backup.5 RESTORE: Label: none RESTORE: Initialize symbol table. RESTORE: Extract directories from tape RESTORE: Warning: cannot create directory /vol/vol0/test/restore: File exists RESTORE: Make node /vol/vol0/test/restore RESTORE: Extract requested files RESTORE: You have not read any tapes yet. Please start with the last tape volume and work towards towards the first. RESTORE: Specify next tape volume #:5 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: rst0a) urst0a RESTORE: Wrong volume 1 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Wrong volume 2 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Wrong volume 3 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Wrong volume 4 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Tape Block size should be 10240, not 64512. RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Tape Block size should be 10240, not 64512. RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) none RESTORE: No more tapes, recovery operation aborted bean>

2 1

Re: SnapMirror Very Slow
by alexei＠mindspring.net 29 Jul '99

29 Jul '99

Sam Schorr <sschorr(a)homestead.com> writes: > Actually, there is a very good reason to do both. Clustering only protects > filer head failures. If a volume on a filer loses 2 disks in 1 RAID group, > the volume built on that RAID group is useless and needs to be rebuilt upon > disk repair. So, by using SNAPMIRROR to "almost realtime" copy data to a > read-only volume on another filer, upon disk failure that volume can be made > "live" or the master volume. This is a strategy we are employing to fully > protect our users' data and insure the highest availability of that data. I am not arguing that doing both is not (potentially) good, but doing both on the same set of filers is troublesome. Individually, each solution addresses a set of problems, and each has its own set of problems. With CF (cluster failover), you get transparent (or close to) failover such that a client does not percieve a failure, just a pause. The cluster partner is then serving both sets of data (its own and that of its partner). If you do not size the filer correctly, you are going to be in trouble, especially if you loose a disk during failover. Snapshots are an additional overhead. With snapmirror, you have a copy of the data N minutes old (where N is a function based on the network latency, the size of the volume (clustermap overhead), size of the network pipe and ammount of deltas). In order to make that copy "live", you will need to update mount points across your clients in order to point at the now-read-write snapmirror volume on the other filer. So, doing snapmirror between cluster members is not a clear win. You are better off snapmirroring to a filer that is not part of the cluster. That way you can isolate your disaster backup copy from any potential problems the cluster might experience. Alex

1 0

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 July 1999