Mailing List Archive

On Tue, Dec 10, 2002 at 12:27:40PM +0530, Kumar, Rahul wrote:
> Hi
>
> Any Ideas why the dump is running so slow. We are running the filer to
> dump onto a SDLT tape drive
>
> DUMP: creating "/vol/vol0/../snapshot_for_backup.0" snapshot.
> DUMP: Using Full Volume Dump
> DUMP: Dumping tape file 1 on /tmp/filer1tape
> DUMP: Date of this level 0 dump: Mon Dec 9 23:02:06 2002.
> DUMP: Date of last level 0 dump: the epoch.
> DUMP: Dumping /vol/vol0/ to root
> DUMP: mapping (Pass I)[regular files]
> DUMP: mapping (Pass II)[directories]
> DUMP: estimated 44482138 KB.
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: Mon Dec 9 23:08:37 2002 : We have written 328738 KB.
> DUMP: Mon Dec 9 23:13:37 2002 : We have written 813336 KB.
> DUMP: Mon Dec 9 23:18:37 2002 : We have written 1248349 KB.

Has it always run at this speed or just this time? If latter, then
try a different tape, I've seen write speed issues with marginal
tapes.

Igor

rahul.kumar@eds.com (Rahul Kumar) writes:
>
> Any Ideas why the dump is running so slow. We are running the filer to
> dump onto a SDLT tape drive
^^^^^^^^^^^^^^^^^

Oh, yeah? In which case why does it say

> DUMP: Dumping tape file 1 on /tmp/filer1tape
^^^^^^^^^^^^^^^

?

If this is dumping to a tape on a remote host, I suppose that _could_ be
a symlink to a tape drive! But in that case, it may be the network that is
the source of your speed problem.

Chris Thompson University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.

Hi All,

This is the speed which I regularly used to get that too oon the same
tape.. We alternate the tapes....
Any help or issues...
Also the tape is attached to a remote host which is a dedicated solaris
box

Regards
Rahul

DUMP: creating "/vol/vol0/../snapshot_for_backup.11" snapshot.
DUMP: Using Full Volume Dump
DUMP: Date of this level 0 dump: Mon Dec 2 23:02:13 2002.
DUMP: Date of last level 0 dump: the epoch.
DUMP: Dumping /vol/vol0/ to root
DUMP: mapping (Pass I)[regular files]
DUMP: mapping (Pass II)[directories]
DUMP: estimated 42147106 KB.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Mon Dec 2 23:08:12 2002 : We have written 971826 KB.
DUMP: Mon Dec 2 23:13:12 2002 : We have written 2639150 KB.
DUMP: Mon Dec 2 23:18:12 2002 : We have written 4115292 KB.
DUMP: Mon Dec 2 23:23:14 2002 : We have written 5679897 KB.
DUMP: Mon Dec 2 23:28:14 2002 : We have written 7306871 KB.
DUMP: Mon Dec 2 23:33:14 2002 : We have written 8830654 KB.
DUMP: Mon Dec 2 23:38:14 2002 : We have written 10476997 KB.
DUMP: Mon Dec 2 23:43:14 2002 : We have written 11551556 KB.
DUMP: Mon Dec 2 23:48:14 2002 : We have written 13048942 KB.
DUMP: Mon Dec 2 23:53:14 2002 : We have written 14688391 KB.
DUMP: Mon Dec 2 23:58:14 2002 : We have written 16221813 KB.
DUMP: Tue Dec 3 00:03:14 2002 : We have written 17364633 KB.
DUMP: Tue Dec 3 00:08:14 2002 : We have written 18843934 KB.
DUMP: Tue Dec 3 00:13:14 2002 : We have written 20516017 KB.
DUMP: Tue Dec 3 00:18:14 2002 : We have written 21848469 KB.
DUMP: Tue Dec 3 00:23:14 2002 : We have written 23232642 KB.
DUMP: Tue Dec 3 00:28:14 2002 : We have written 24980200 KB.
DUMP: Tue Dec 3 00:33:14 2002 : We have written 26645288 KB.
DUMP: Tue Dec 3 00:38:14 2002 : We have written 28013082 KB.
DUMP: Tue Dec 3 00:43:14 2002 : We have written 29653350 KB.
DUMP: Tue Dec 3 00:48:14 2002 : We have written 31112304 KB.
DUMP: Tue Dec 3 00:53:14 2002 : We have written 32806123 KB.
DUMP: Tue Dec 3 00:58:14 2002 : We have written 34071851 KB.
DUMP: Tue Dec 3 01:03:14 2002 : We have written 35518838 KB.
DUMP: Tue Dec 3 01:08:14 2002 : We have written 36825522 KB.
DUMP: Tue Dec 3 01:13:14 2002 : We have written 38524506 KB.
DUMP: Tue Dec 3 01:18:14 2002 : We have written 39836545 KB.
DUMP: Tue Dec 3 01:23:14 2002 : We have written 41444950 KB.
DUMP: dumping (Pass V) [ACLs]
DUMP: 42121234 KB
DUMP: DUMP IS DONE

-----Original Message-----
From: Chris Thompson [mailto:cet1@cus.cam.ac.uk]
Sent: Tuesday, December 10, 2002 2:22 PM
To: Kumar, Rahul
Cc: toasters@mathworks.com
Subject: Re: Dump issue


rahul.kumar@eds.com (Rahul Kumar) writes:
>
> Any Ideas why the dump is running so slow. We are running the filer to

> dump onto a SDLT tape drive
^^^^^^^^^^^^^^^^^

Oh, yeah? In which case why does it say

> DUMP: Dumping tape file 1 on /tmp/filer1tape
^^^^^^^^^^^^^^^

?

If this is dumping to a tape on a remote host, I suppose that _could_ be
a symlink to a tape drive! But in that case, it may be the network that
is the source of your speed problem.

Chris Thompson University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.

Hi
As you can see its only 40gb data off from 119 gb vol0

Rahul

-----Original Message-----
From: Kumar, Sreejith [mailto:Sreejith_Kumar@mentorg.com]
Sent: Tuesday, December 10, 2002 3:51 PM
To: Kumar, Rahul
Subject: Re: Dump issue


Is your netapp over 70-80% capacity ? We had seen similar problems with
dump when the filer reaches 70-80% capacity.

Sreejith
----- Original Message -----
From: "Kumar, Rahul" <rahul.kumar@eds.com>
To: "Chris Thompson" <cet1@cus.cam.ac.uk>
Cc: <toasters@mathworks.com>
Sent: Tuesday, December 10, 2002 3:08 PM
Subject: RE: Dump issue


> Hi All,
>
> This is the speed which I regularly used to get that too oon the same
> tape.. We alternate the tapes.... Any help or issues...
> Also the tape is attached to a remote host which is a dedicated
solaris
> box
>
> Regards
> Rahul
>
> DUMP: creating "/vol/vol0/../snapshot_for_backup.11" snapshot.
> DUMP: Using Full Volume Dump
> DUMP: Date of this level 0 dump: Mon Dec 2 23:02:13 2002.
> DUMP: Date of last level 0 dump: the epoch.
> DUMP: Dumping /vol/vol0/ to root
> DUMP: mapping (Pass I)[regular files]
> DUMP: mapping (Pass II)[directories]
> DUMP: estimated 42147106 KB.
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: Mon Dec 2 23:08:12 2002 : We have written 971826 KB.
> DUMP: Mon Dec 2 23:13:12 2002 : We have written 2639150 KB.
> DUMP: Mon Dec 2 23:18:12 2002 : We have written 4115292 KB.
> DUMP: Mon Dec 2 23:23:14 2002 : We have written 5679897 KB.
> DUMP: Mon Dec 2 23:28:14 2002 : We have written 7306871 KB.
> DUMP: Mon Dec 2 23:33:14 2002 : We have written 8830654 KB.
> DUMP: Mon Dec 2 23:38:14 2002 : We have written 10476997 KB.
> DUMP: Mon Dec 2 23:43:14 2002 : We have written 11551556 KB.
> DUMP: Mon Dec 2 23:48:14 2002 : We have written 13048942 KB.
> DUMP: Mon Dec 2 23:53:14 2002 : We have written 14688391 KB.
> DUMP: Mon Dec 2 23:58:14 2002 : We have written 16221813 KB.
> DUMP: Tue Dec 3 00:03:14 2002 : We have written 17364633 KB.
> DUMP: Tue Dec 3 00:08:14 2002 : We have written 18843934 KB.
> DUMP: Tue Dec 3 00:13:14 2002 : We have written 20516017 KB.
> DUMP: Tue Dec 3 00:18:14 2002 : We have written 21848469 KB.
> DUMP: Tue Dec 3 00:23:14 2002 : We have written 23232642 KB.
> DUMP: Tue Dec 3 00:28:14 2002 : We have written 24980200 KB.
> DUMP: Tue Dec 3 00:33:14 2002 : We have written 26645288 KB.
> DUMP: Tue Dec 3 00:38:14 2002 : We have written 28013082 KB.
> DUMP: Tue Dec 3 00:43:14 2002 : We have written 29653350 KB.
> DUMP: Tue Dec 3 00:48:14 2002 : We have written 31112304 KB.
> DUMP: Tue Dec 3 00:53:14 2002 : We have written 32806123 KB.
> DUMP: Tue Dec 3 00:58:14 2002 : We have written 34071851 KB.
> DUMP: Tue Dec 3 01:03:14 2002 : We have written 35518838 KB.
> DUMP: Tue Dec 3 01:08:14 2002 : We have written 36825522 KB.
> DUMP: Tue Dec 3 01:13:14 2002 : We have written 38524506 KB.
> DUMP: Tue Dec 3 01:18:14 2002 : We have written 39836545 KB.
> DUMP: Tue Dec 3 01:23:14 2002 : We have written 41444950 KB.
> DUMP: dumping (Pass V) [ACLs]
> DUMP: 42121234 KB
> DUMP: DUMP IS DONE
>
> -----Original Message-----
> From: Chris Thompson [mailto:cet1@cus.cam.ac.uk]
> Sent: Tuesday, December 10, 2002 2:22 PM
> To: Kumar, Rahul
> Cc: toasters@mathworks.com
> Subject: Re: Dump issue
>
>
> rahul.kumar@eds.com (Rahul Kumar) writes:
> >
> > Any Ideas why the dump is running so slow. We are running the filer
> > to
>
> > dump onto a SDLT tape drive
> ^^^^^^^^^^^^^^^^^
>
> Oh, yeah? In which case why does it say
>
> > DUMP: Dumping tape file 1 on /tmp/filer1tape
> ^^^^^^^^^^^^^^^
>
> ?
>
> If this is dumping to a tape on a remote host, I suppose that _could_
> be a symlink to a tape drive! But in that case, it may be the network
> that is the source of your speed problem.
>
> Chris Thompson University of Cambridge Computing
Service,
> Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH,
> Phone: +44 1223 334715 United Kingdom.

We are seeing very similar performance issues from our F840Cs. We have
opened a case with NetApps, but have received very little information back
from them.

In our case, a 3 drive volume backing up gzip'ed files maxes out our SDLT
drives at nearly 11 MB/sec. We have a 6 drive volume of highly
compressible information that will stream to tape at over 20 MB/sec.
However, a 7 drive volume that only contains a few dozen very large Oracle
datafiles, now at times struggles to write 4 MB/sec!

The only correlation that I can make is that when disk utilization goes
above 40%, the backup speed plummets below 10 MB/sec. Have you tried
running sysstat or statit during the backup?

My biggest concern is that this may be the first symptom of some major
problem. If 7 drives can't read faster than 4MB/sec, then wouldn't you be
a little worried?

SomeBody in Netapp Needs to look at this !

-----Original Message-----
From: Ambrose_Earle@shamrockfoods.com
[mailto:Ambrose_Earle@shamrockfoods.com]
Sent: Tuesday, December 10, 2002 9:00 PM
To: Kumar, Rahul
Cc: toasters@mathworks.com
Subject: Re: Dump issue




We are seeing very similar performance issues from our F840Cs. We have
opened a case with NetApps, but have received very little information
back from them.

In our case, a 3 drive volume backing up gzip'ed files maxes out our
SDLT drives at nearly 11 MB/sec. We have a 6 drive volume of highly
compressible information that will stream to tape at over 20 MB/sec.
However, a 7 drive volume that only contains a few dozen very large
Oracle datafiles, now at times struggles to write 4 MB/sec!

The only correlation that I can make is that when disk utilization goes
above 40%, the backup speed plummets below 10 MB/sec. Have you tried
running sysstat or statit during the backup?

My biggest concern is that this may be the first symptom of some major
problem. If 7 drives can't read faster than 4MB/sec, then wouldn't you
be a little worried?

I am writing 11gb from an F760 to a single dlt7000 on a sun 220r. Finishes
in 40 minutes

art hebert


DUMP: creating "/vol/vol0/../snapshot_for_backup.195" snapshot.
DUMP: Using subtree dump
DUMP: Date of this level 0 dump: Tue Dec 10 13:06:44 2002.
DUMP: Date of last level 0 dump: the epoch.
DUMP: Dumping /vol/vol0/home/db_backup to sjcswm01
DUMP: mapping (Pass I)[regular files]
DUMP: mapping (Pass II)[directories]
DUMP: estimated 11405409 KB.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Tue Dec 10 13:11:53 2002 : We have written 1246308 KB.
DUMP: Tue Dec 10 13:16:53 2002 : We have written 2547789 KB.
DUMP: Tue Dec 10 13:21:53 2002 : We have written 3884289 KB.
DUMP: Tue Dec 10 13:26:53 2002 : We have written 5186734 KB.
DUMP: Tue Dec 10 13:31:53 2002 : We have written 6496818 KB.
DUMP: Tue Dec 10 13:36:53 2002 : We have written 7694731 KB.
DUMP: Tue Dec 10 13:41:53 2002 : We have written 9001257 KB.
DUMP: Tue Dec 10 13:46:53 2002 : We have written 10341265 KB.
DUMP: dumping (Pass V) [ACLs]
DUMP: 11408523 KB
DUMP: DUMP IS DONE


-----Original Message-----
From: Kumar, Rahul [mailto:rahul.kumar@eds.com]
Sent: Tuesday, December 10, 2002 7:40 AM
To: Ambrose_Earle@shamrockfoods.com
Cc: toasters@mathworks.com
Subject: RE: Dump issue


SomeBody in Netapp Needs to look at this !

-----Original Message-----
From: Ambrose_Earle@shamrockfoods.com
[mailto:Ambrose_Earle@shamrockfoods.com]
Sent: Tuesday, December 10, 2002 9:00 PM
To: Kumar, Rahul
Cc: toasters@mathworks.com
Subject: Re: Dump issue




We are seeing very similar performance issues from our F840Cs. We have
opened a case with NetApps, but have received very little information
back from them.

In our case, a 3 drive volume backing up gzip'ed files maxes out our
SDLT drives at nearly 11 MB/sec. We have a 6 drive volume of highly
compressible information that will stream to tape at over 20 MB/sec.
However, a 7 drive volume that only contains a few dozen very large
Oracle datafiles, now at times struggles to write 4 MB/sec!

The only correlation that I can make is that when disk utilization goes
above 40%, the backup speed plummets below 10 MB/sec. Have you tried
running sysstat or statit during the backup?

My biggest concern is that this may be the first symptom of some major
problem. If 7 drives can't read faster than 4MB/sec, then wouldn't you
be a little worried?

Also would be interesting to know
how many inodes on the file system.

Martin

-----Original Message-----
From: Kumar, Rahul [mailto:rahul.kumar@eds.com]
Sent: Monday, December 09, 2002 10:58 PM
To: toasters@mathworks.com
Subject: Dump issue
Importance: High


Hi

Any Ideas why the dump is running so slow. We are running the filer to
dump onto a SDLT tape drive

DUMP: creating "/vol/vol0/../snapshot_for_backup.0" snapshot.
DUMP: Using Full Volume Dump
DUMP: Dumping tape file 1 on /tmp/filer1tape
DUMP: Date of this level 0 dump: Mon Dec 9 23:02:06 2002.
DUMP: Date of last level 0 dump: the epoch.
DUMP: Dumping /vol/vol0/ to root
DUMP: mapping (Pass I)[regular files]
DUMP: mapping (Pass II)[directories]
DUMP: estimated 44482138 KB.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Mon Dec 9 23:08:37 2002 : We have written 328738 KB.
DUMP: Mon Dec 9 23:13:37 2002 : We have written 813336 KB.
DUMP: Mon Dec 9 23:18:37 2002 : We have written 1248349 KB.
DUMP: Mon Dec 9 23:23:37 2002 : We have written 1780575 KB.
DUMP: Mon Dec 9 23:28:37 2002 : We have written 2307507 KB.
DUMP: Mon Dec 9 23:33:37 2002 : We have written 2782586 KB.
DUMP: Mon Dec 9 23:38:37 2002 : We have written 3220125 KB.
DUMP: Mon Dec 9 23:43:37 2002 : We have written 3751844 KB.
DUMP: Mon Dec 9 23:48:37 2002 : We have written 4190113 KB.
DUMP: Mon Dec 9 23:53:37 2002 : We have written 4641781 KB.
DUMP: Mon Dec 9 23:58:37 2002 : We have written 5080513 KB.
DUMP: Tue Dec 10 00:03:37 2002 : We have written 5606338 KB.
DUMP: Tue Dec 10 00:08:37 2002 : We have written 6088137 KB.
DUMP: Tue Dec 10 00:13:37 2002 : We have written 6572608 KB.
DUMP: Tue Dec 10 00:18:37 2002 : We have written 7016947 KB.
DUMP: Tue Dec 10 00:23:37 2002 : We have written 7542679 KB.
DUMP: Tue Dec 10 00:28:37 2002 : We have written 7984060 KB.
DUMP: Tue Dec 10 00:33:37 2002 : We have written 8503801 KB.
DUMP: Tue Dec 10 00:38:37 2002 : We have written 8958353 KB.
DUMP: Tue Dec 10 00:43:37 2002 : We have written 9390217 KB.
DUMP: Tue Dec 10 00:48:37 2002 : We have written 9828824 KB.
DUMP: Tue Dec 10 00:53:37 2002 : We have written 10260501 KB.


Rahul

Rahul,

You're dumping to a remotely attached linear tape drive.

I have seen this kind of thing many times with DLT drives (of all flavours).

If the network link can't quite keep up with the drive for a moment due to
other network loads (or lots of seek on the filer due to large number of
inodes), the drive stops and rewinds ("backhitching"). The time it takes to
do this is hundreds of times longer than the momentary network congestion,
so this plays havoc with the I/O queuing on the host the tape is attached
to, which causes "dump" on the filer to back off and wait because it's not
getting RMT verifies. This results in even more sporadic gaps in the stream
to the tape drive, which backhitches more....

i.e. you end up in a vicious circle of performance degradation. The speed
variance available in SDLT is not enough to prevent backhitching.

The cures:

1) Attach the tape drive to the filer!

2) Provide dedicated bandwidth for the backup - i.e. a crossover gigabit
link between the Sun box and the filer. (private subnet IP range as well of
course)

3) Replace the SDLT with a non-linear tape that doesn't backhitch - i.e.
AIT3 or VXA2. AIT3 is IMHO superior to SDLT in many ways.


All of these options will cost you money - even (1) if you need to then buy
NetVault so you can backup all the other servers' local disks to the tape
attached to the filer. But obviously budget is a problem or you wouldn't be
using dump.

Hope this helps.

Alan.



-----Original Message-----
From: Kumar, Rahul [mailto:rahul.kumar@eds.com]
Sent: Tuesday, 10 December 2002 5:58 PM
To: toasters@mathworks.com
Subject: Dump issue
Importance: High


Hi

Any Ideas why the dump is running so slow. We are running the filer to
dump onto a SDLT tape drive

DUMP: creating "/vol/vol0/../snapshot_for_backup.0" snapshot.
DUMP: Using Full Volume Dump
DUMP: Dumping tape file 1 on /tmp/filer1tape
DUMP: Date of this level 0 dump: Mon Dec 9 23:02:06 2002.
DUMP: Date of last level 0 dump: the epoch.
DUMP: Dumping /vol/vol0/ to root
DUMP: mapping (Pass I)[regular files]
DUMP: mapping (Pass II)[directories]
DUMP: estimated 44482138 KB.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Mon Dec 9 23:08:37 2002 : We have written 328738 KB.
DUMP: Mon Dec 9 23:13:37 2002 : We have written 813336 KB.
DUMP: Mon Dec 9 23:18:37 2002 : We have written 1248349 KB.
DUMP: Mon Dec 9 23:23:37 2002 : We have written 1780575 KB.
DUMP: Mon Dec 9 23:28:37 2002 : We have written 2307507 KB.
DUMP: Mon Dec 9 23:33:37 2002 : We have written 2782586 KB.
DUMP: Mon Dec 9 23:38:37 2002 : We have written 3220125 KB.
DUMP: Mon Dec 9 23:43:37 2002 : We have written 3751844 KB.
DUMP: Mon Dec 9 23:48:37 2002 : We have written 4190113 KB.
DUMP: Mon Dec 9 23:53:37 2002 : We have written 4641781 KB.
DUMP: Mon Dec 9 23:58:37 2002 : We have written 5080513 KB.
DUMP: Tue Dec 10 00:03:37 2002 : We have written 5606338 KB.
DUMP: Tue Dec 10 00:08:37 2002 : We have written 6088137 KB.
DUMP: Tue Dec 10 00:13:37 2002 : We have written 6572608 KB.
DUMP: Tue Dec 10 00:18:37 2002 : We have written 7016947 KB.
DUMP: Tue Dec 10 00:23:37 2002 : We have written 7542679 KB.
DUMP: Tue Dec 10 00:28:37 2002 : We have written 7984060 KB.
DUMP: Tue Dec 10 00:33:37 2002 : We have written 8503801 KB.
DUMP: Tue Dec 10 00:38:37 2002 : We have written 8958353 KB.
DUMP: Tue Dec 10 00:43:37 2002 : We have written 9390217 KB.
DUMP: Tue Dec 10 00:48:37 2002 : We have written 9828824 KB.
DUMP: Tue Dec 10 00:53:37 2002 : We have written 10260501 KB.


Rahul


**** ASI Solutions Disclaimer ****
The material transmitted may contain confidential and/or privileged
material and is intended only for the addressee. If you receive this in
error, please notify the sender and destroy any copies of the material
immediately. ASI will protect your Privacy according to the 10 Privacy
Principles outlined under the new Privacy Act, Dec 2001.

This email is also subject to copyright. Any use of or reliance upon this
material by persons or entities other than the addressee is prohibited.

E-mails may be interfered with, may contain computer viruses or other
defects. Under no circumstances do we accept liability for any loss or
damage which may result from your receipt of this message or any
attachments.
**** END OF MESSAGE ****

As others have suggested, this must be due to network congestion
or a *very* large number of files/inodes in the volume.

I've been testing a new customer implementation today and just
saw 80MB/sec from an F840, backing up 3 volumes to 3 fibre
attached IBM LTOs in parallel. We getting aggregate throughputs
of up to 180GB/hr. DOT version is 6.1R3.

The data is a mix of database and many small files.

How many spindles are your volumes striped over ?

D
#
----- Original Message -----
From: "Kumar, Rahul" <rahul.kumar@eds.com>
To: <Ambrose_Earle@shamrockfoods.com>
Cc: <toasters@mathworks.com>
Sent: Tuesday, December 10, 2002 3:40 PM
Subject: RE: Dump issue


> SomeBody in Netapp Needs to look at this !
>
> -----Original Message-----
> From: Ambrose_Earle@shamrockfoods.com
> [mailto:Ambrose_Earle@shamrockfoods.com]
> Sent: Tuesday, December 10, 2002 9:00 PM
> To: Kumar, Rahul
> Cc: toasters@mathworks.com
> Subject: Re: Dump issue
>
>
>
>
> We are seeing very similar performance issues from our F840Cs. We have
> opened a case with NetApps, but have received very little information
> back from them.
>
> In our case, a 3 drive volume backing up gzip'ed files maxes out our
> SDLT drives at nearly 11 MB/sec. We have a 6 drive volume of highly
> compressible information that will stream to tape at over 20 MB/sec.
> However, a 7 drive volume that only contains a few dozen very large
> Oracle datafiles, now at times struggles to write 4 MB/sec!
>
> The only correlation that I can make is that when disk utilization goes
> above 40%, the backup speed plummets below 10 MB/sec. Have you tried
> running sysstat or statit during the backup?
>
> My biggest concern is that this may be the first symptom of some major
> problem. If 7 drives can't read faster than 4MB/sec, then wouldn't you
> be a little worried?
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.419 / Virus Database: 235 - Release Date: 13/11/2002