toasters

toasters@lists.teaparty.net

13520 discussions

Power usage.
by Jordan Share 01 Aug '01

01 Aug '01

Does anyone know where I can get information on the number of Amps drawn by a 740 and 2 shelves? I'm trying to determine how much power needs to be available for my colo install. Thanks, Jordan

1 0

RE: F760 cluster write performance
by Art Hebert 01 Aug '01

01 Aug '01

We ran into the same problem on 100mb, copying a 100mb file to the netapp took 23 seconds. We moved the 100mb nic off of the 32bit bus onto the 64 bit bus and the time to copy the file dropped to 11.5 seconds. This is unsupported but it works. What slot is your gig nic in? art hebert -----Original Message----- From: Allen Belletti [mailto:abelletti@dmotorworks.com] Sent: Tuesday, July 31, 2001 4:39 PM To: toasters(a)mathworks.com Subject: F760 cluster write performance Hello, We've been running a pair of clustered F760's since about February. Among other things, we are using them for Oracle database storage, with the hosts being Suns running Solaris 7 or 8. The interconnect is via gigabit Ethernet through a Cisco 3508 switch. We're doing NFS service only -- no CIFS. The volumes in question are between 60 and 80% full, and consist of between ten and 14 drives, either 18G or 36G depending on the volume. OS version is 6.1R1. NFS mounts are using UDP, version 3, rsize=32768, wsize=32768 (though Netapp has suggested reducing this to 8k). Recently, we have been running up against the limit of the F760's write performance, or so it seems. At best, a single (GigE connected) host is able to do 7-8MB/s of sustained sequential write traffic. These same hosts are able to read at greater than 30 MB/sec and sometimes as high as 50 MB/sec if the data is all in cache on the Netapp. What I'd really like to know is what kind of sustained write rates other folks are seeing in configurations similar to this one. At the very least, if you have any kind of F760 cluster, even without gigabit Ethernet, are you able to do more than 7-8MB sustained write? Also, when the writes are occurring, the filer CPU load is generally very high, anywhere from 80 to 100%. Disk utilitization is more reasonable, around 50% if the filer is not otherwise busy. My first thought (and Netapp's as well) would be that this is some kind of network problem, perhaps relating to GigE flow control. However, if this were the case I would expect the Filer CPU load to be lower. If anyone has seen (or fixed!) anything like this, I would appreciate any suggestions or advice. Thanks in advance, Allen Belletti System Administrator Digital Motorworks Phone: 512-692-1024 Fax: 512-349-9366 abelletti(a)digitalmotorworks.com www.digitalmotorworks.com -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Andrew Smith Sent: Monday, April 23, 2001 12:58 PM To: toasters(a)mathworks.com Subject: dump to remote device via rmt Hello, I've been dumping my filer to a remote HP DDS-4 drive on a RedHat Linux machine. It's been working great. But now I have more data on my filer than one DDS-4 tape will hold for a level-0 dump. Are there any issues with spanning more than one tape for a dump via rmt? Here is the output of my dump run: DUMP: Dumping tape file 1 on /dev/nst0 DUMP: creating "/vol/vol0/../snapshot_for_backup.3" snapshot. DUMP: Using Full Volume Dump DUMP: Date of this level 0 dump: Mon Apr 23 10:40:26 2001. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/vol0/ to dumper DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 24452615 KB. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Mon Apr 23 10:46:54 2001 : We have written 560012 KB. [... lines removed ...] DUMP: Mon Apr 23 12:37:04 2001 : We have written 21097444 KB. DUMP: Remote write failed: RMT bad response from client DUMP: DUMP IS ABORTED DUMP: Deleting "/vol/vol0/../snapshot_for_backup.3" snapshot. Is there a way I can have dump prompt me to change volumes? I haven't been able to find much information on the subject. Thanks! -Andrew Smith DCANet

1 0

dump to remote device via rmt
by Andrew Smith 31 Jul '01

31 Jul '01

Hello, I've been dumping my filer to a remote HP DDS-4 drive on a RedHat Linux machine. It's been working great. But now I have more data on my filer than one DDS-4 tape will hold for a level-0 dump. Are there any issues with spanning more than one tape for a dump via rmt? Here is the output of my dump run: DUMP: Dumping tape file 1 on /dev/nst0 DUMP: creating "/vol/vol0/../snapshot_for_backup.3" snapshot. DUMP: Using Full Volume Dump DUMP: Date of this level 0 dump: Mon Apr 23 10:40:26 2001. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/vol0/ to dumper DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 24452615 KB. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Mon Apr 23 10:46:54 2001 : We have written 560012 KB. [... lines removed ...] DUMP: Mon Apr 23 12:37:04 2001 : We have written 21097444 KB. DUMP: Remote write failed: RMT bad response from client DUMP: DUMP IS ABORTED DUMP: Deleting "/vol/vol0/../snapshot_for_backup.3" snapshot. Is there a way I can have dump prompt me to change volumes? I haven't been able to find much information on the subject. Thanks! -Andrew Smith DCANet

3 2

Veritas b/u not clearing archive bit on NetApp volume
by Adrian Phillips 31 Jul '01

31 Jul '01

Hello List; We have an F760 running CIFS, with ONTAP 6.0.1R3. "C:" is mapped to vol0, and "D:" to vol1. We use Veritas BackupExec 8.5 over the network to connect to and back up the data/shares on these NTFS volumes. What is very odd (and I nor Netapp can seem to figure out thus far) is that the archive bit for files on C: do not get reset after full or incremental backups. Meanwhile, through the same backup jobs, the archive bit on files on drive D: DOES get properly cleared after being backed up. Because the archive bit is not being cleared on C:, our incremental backups are very large, and running well into the work day. I can't seem to find any differences in the volumes, other than vol0/C: is the root volume and uses 9GB drives, compared to vol1/D:'s 36GB drives. Regards, -Adrian

1 0

RE: snapmirror volume sizes
by Fox, Adam 31 Jul '01

31 Jul '01

While this is true, it is a block for block copy which is why you still have to have at least the same # of blocks on the destination as you have on the source. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: Mike Federwisch [mailto:mikef@netapp.com] > Sent: Monday, July 30, 2001 7:38 PM > To: Jeffrey Krueger > Cc: Knight, Jason; 'Kelly McQuarrie'; toasters(a)mathworks.com > Subject: Re: snapmirror volume sizes > > > Actually, volcopy and snapmirror only transfer the used blocks. > Unused blocks are not transferred. As and exercise, create a > large volume with nothing in it. volcopy it to another volume > and since the source has little data, you will notice that > the transfer > is very short even though the volume is large. > > Mike Federwisch > > > > Really would be cool if volcopy and snapmirror could > differentiate between > > used and un-used blocks and not require the copy of the > un-used ones. =) > > > > Actually, it would be more than cool. It would be very cool. > > > > -- Jeff > > > > > > > > On Mon, Jul 30, 2001 at 04:24:20PM -0500, Knight, Jason wrote: > > > Kelly, > > > > > > You are correct. Same size volumes. > > > > > > NDMPCOPY is a way to achieve the goal, it is a utility > available on NOW and > > > it basically does a backup of one filer and restore to > another (or the same > > > filer) concurrently. > > > > > > > > > > > > Jason Knight > > > > > > > > > > > > > > > -----Original Message----- > > > From: Kelly McQuarrie [mailto:kellym@sd.us.am.ericsson.se] > > > Sent: Monday, July 30, 2001 3:32 PM > > > To: toasters(a)mathworks.com > > > Subject: snapmirror volume sizes > > > > > > > > > Hello all: > > > > > > I think I know that answer to this one but I figured I > would put it out here > > > just to make sure I'm right. > > > > > > I wanted to use snapmirror to migrate a volume to a > different filer. This > > > volume is 225Gigs but it only has 68Gigs of data on it. > If I'm to use > > > snapmirror to do this then I need to migrate it to a > 225Gig volume correct? > > > I wanted to shrink the volume while I was at it so I'm > thinking I'm going to > > > have to do it another way. > > > > > > Has anybody had experience with this? > > > > > > Thx > > > > > > Kelly McQuarrie > > > Unix System Administrator > > > Ericsson CDMA Systems > > > > >

1 0

RE: snapmirror volume sizes
by Knight, Jason 31 Jul '01

31 Jul '01

Kelly, You are correct. Same size volumes. NDMPCOPY is a way to achieve the goal, it is a utility available on NOW and it basically does a backup of one filer and restore to another (or the same filer) concurrently. Jason Knight -----Original Message----- From: Kelly McQuarrie [mailto:kellym@sd.us.am.ericsson.se] Sent: Monday, July 30, 2001 3:32 PM To: toasters(a)mathworks.com Subject: snapmirror volume sizes Hello all: I think I know that answer to this one but I figured I would put it out here just to make sure I'm right. I wanted to use snapmirror to migrate a volume to a different filer. This volume is 225Gigs but it only has 68Gigs of data on it. If I'm to use snapmirror to do this then I need to migrate it to a 225Gig volume correct? I wanted to shrink the volume while I was at it so I'm thinking I'm going to have to do it another way. Has anybody had experience with this? Thx Kelly McQuarrie Unix System Administrator Ericsson CDMA Systems

5 4

RE: snapmirror volume sizes
by Fox, Adam 30 Jul '01

30 Jul '01

With SnapMirror (and vol copy for that matter), you must have at least the same amount of TOTAL space on the destination as you have on the source. This is because SnapMirror is a block for block copy. To move data to a smaller volume, you'll need to do something like ndmpcopy. This works well for the scenario you describe. Hope this helps. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: Kelly McQuarrie [mailto:kellym@sd.us.am.ericsson.se] > Sent: Monday, July 30, 2001 4:32 PM > To: toasters(a)mathworks.com > Subject: snapmirror volume sizes > > > Hello all: > > I think I know that answer to this one but I figured I would > put it out > here just to make sure I'm right. > > I wanted to use snapmirror to migrate a volume to a different > filer. This > volume is 225Gigs but it only has 68Gigs of data on it. If I'm to use > snapmirror to do this then I need to migrate it to a 225Gig volume > correct? I wanted to shrink the volume while I was at it so > I'm thinking > I'm going to have to do it another way. > > Has anybody had experience with this? > > Thx > > Kelly McQuarrie > Unix System Administrator > Ericsson CDMA Systems >

1 0

snapmirror volume sizes
by Kelly McQuarrie 30 Jul '01

30 Jul '01

Hello all: I think I know that answer to this one but I figured I would put it out here just to make sure I'm right. I wanted to use snapmirror to migrate a volume to a different filer. This volume is 225Gigs but it only has 68Gigs of data on it. If I'm to use snapmirror to do this then I need to migrate it to a 225Gig volume correct? I wanted to shrink the volume while I was at it so I'm thinking I'm going to have to do it another way. Has anybody had experience with this? Thx Kelly McQuarrie Unix System Administrator Ericsson CDMA Systems

1 0

Old marketing numbers?
by Davin Milun 30 Jul '01

30 Jul '01

Hi all, Does anyone know exactly which shelf types correspond to the marketing codes X641 and X643C? I believe that they're both SCSI shelves, but I don't know which models. Thanks. Davin. -- Davin Milun Juno Online Services, Inc. milun(a)staff.juno.com http://www.juno.com/

1 0

Used NetApp
by SSlagle＠eCompanies.com 27 Jul '01

27 Jul '01

What is the best resources for finding used Network Appliance equipment? --- Stuart Slagle Network Engineering, eCompanies Wireless sslagle(a)ecompanies.com 310-586-4215

2 1

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