toasters

toasters@lists.teaparty.net

1 participants
13528 discussions

snmpwalk on NetApp 5.0 problem
by Daniel Quinlan 13 Apr '98

13 Apr '98

We seem to be unable to use snmpwalk on NetApp 5.0 and 5.0R1. We're using UCD-snmp version 3.3.1 to retrieve data as well as the latest out-of-date NetApp MIB. SNMP works fine for us on 4.3.1 and earlier versions. The problem is that we can't walk the entire SNMP tree -- it fails after barely starting. It does seem possible to access later portions of the tree, but only if you know they exist and ask specifically for a smaller part of the tree. Here's the UCD-snmp environment variables we're using: export MIBFILE=/usr/local/share/snmp/mibs/netapp.mib export PREFIX=.iso.org.dod.internet.private.enterprises I was wondering if anyone else does or does not have this problem. Thanks for any info. - Dan

1 0

RE: 4GB/9GB shelf migration from toaster A to toaster B.
by grant＠netapp.com 10 Apr '98

10 Apr '98

Hi Thomas, > [Weeks, Thomas] > What's this multivolume thing? > From 5.0 Data ONTAP has support for multiple filesystems on each filer. Each filesystem is termed a volume and each volume has support for multiple raid groups, i.e. more than one (parity + data) disk set. So now (well soon) you can take your TB+ filer and configure it with 5+ x 200GB volumes, etc And you can download 5.0R1 from NOW today! The major features in Release 5.0R1 are support for Multiple Raid Groups, Multiple Volume File systems and Fibre Channel disks. > > [Weeks, Thomas] > When we bought a new filer (FAS1400-->FS230) we just used > NDMPcopy to go from the old filer to the new filer... > > We got around 5Mbps xfer rates, powered down the old server, > powered up the new server and ran.. keeping the old server in the rack > for a week just in case. > Cool! Just so you know with 4.3 releases you can migrate a whole filer even faster by asking your S.E. to turn up with his Bare Metal Migrate floppies and it supports FAS1400 hardware! Cheers, Grant

1 0

450 and a network switch
by Mark Richards 10 Apr '98

10 Apr '98

Hello I'm having a problem with my 450 (running 4.3.3) when it is connected to a LanCast 10mbp switch. Put simply. performance is terrible when switch is in my network and clients are acessing the 450 (which is attached to the switch with a crossover cable). If I remove the the switch from the network, all is well. I've sent the switch back to be tested and it is fine. Other UNIX servers in my network give great performance with or with the switch as do the clients. I've thought about half/full duplex issues on the 450's ethernet but its set correctly on the netapp and I've read that the 450 does support full-duplex anyway. Any ideas as to why my 450 doesn't like the switch? Regards Mark Richards

3 2

Re: 4GB/9GB shelf migration from toaster A to toaster B.
by sirbruce＠ix.netcom.com 10 Apr '98

10 Apr '98

On 04/09/98 16:50:02 you wrote: >Here's my theory as to the cause (translation: guess): > >The netapp mirrors the OS on the header of all the disks. > >At least half of the disks must have the same OS copy/version/checksum/magic-number >in order for the netapp to boot correctly (guess #1) Well, if true, this would have to be a new thing with respect to the OS version... it would just boot whatever OS it found "first". The "first" disk is usually the same every reboot, but circumstances (as well as simple chance) can change this. You're right about the magic-number stuff, but I think there is more than one magic-number to consider. >The "vol destroy" uses a hardware-quick-erase feature which blows away the whole >disk, not just the data portion. This blows away the OS portion of the disk. > >Viola! After a vol destroy on 22 of my 24 disks, I now have a valid OS on less >than half the disks. Non-floppy boots fail until I get it up with a floppy, and >run download (but no data is lost). The only thing that doesn't make sense to me in this theory is that if the header is invalid, then the disk will just show up as such and have to be reinitialized. But there are various types of headers on the disks and they are looked at in different ways, so the matter is probably much more complicated. My guess is the vol destroy just isn't handling the header correctly, not that the software isn't getting downloaded to it. (The latter might also be true.) Bruce

1 0

Re: 4GB/9GB shelf migration from toaster A to toaster B.
by grant＠netapp.com 09 Apr '98

09 Apr '98

Hi Jim, Jim Davis <jdavis(a)CS.Arizona.EDU> writes: > Potential plan: buy a shelf of 9GB disks, put it on toaster A, move a > shelf of 4GB disks to toaster B, keeping all of the toaster A data on > toaster A. Toaster B ends up with an empty file system on its 4GB disk > shelf. > > Now the mechanics of the move are a little unclear to me. Presumably we > hook up the 9GB shelf to toaster A and 'raid fail' each 4GB disk in the > shelf we want to move? But there will be 5 9GB data disks, since we have > to burn one as a hot spare and one becomes the new parity disk. Will > there be a problem with having 7 disks to move data from, but only 5 disks > to move data to? There would be enough GBs on the 5 9GB disks, but... I'd propose this plan of action: Buy enough 9GB disks to support all data resident on 4GB disks. Install Data ONTAP 5.0. Attach 9GB disks and create second volume. Run NDMPcopy to transfer vol0 -> vol1 (special care required if you use incrementals). Make vol1 the root volume Offline & destroy vol0 after vol1 deemed okay! Break up 4GB disks between filer A & B. Create second volume on Filer A using leftover 4GB disks. Alternative is: dump data to tape (quota trees would be useful) Break up 4GB disks between filer A & B Add 2 volumes to Filer A using 4GB & 9GB disks restore from tape to any volume (again quota trees would be useful) You have to get *all* the data off the 4GB disks before you can free any of them up (as Dan already pointed out). We don't have an EVACUATE command. Note for the future: We aim to have a volume copy command in a future release that will allow a larger volume (measured by disk capacity) to be transferred to a smaller volume (measured by disk capacity) as long as the resident data will fit. You will need to use NDMPcopy to transfer the volume if you do it with one filer and multiple volumes since BareMetal Migrate is only available in the 4.3. software release. With two (single volume) filers in play BareMetal Migrate is just the ticket. Cheers, Grant

2 1

Re: Fun with NDMP
by grant＠netapp.com 09 Apr '98

09 Apr '98

Hi Tripp, > > I have successfully (I think) ported ndmpcopy to Digital Unix, > Cool! Any chance you can contribute your changes back to ftp.ndmp.org. If you leave the code in /incoming. I'll make sure it makes its way to the contrib directory. > > but I am running into some problems trying to initiate a copy. > Boo. Hiss. > > adminhost# ./ndmpcopy srcfiler:/ms/ftp destfiler:/ftp -sa > root:passwd -da root:passwd -level 0 -v > > srcfiler> Thu Apr 9 17:09:12 EDT [ndmp_session_0]: > ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: > No route to host > > destfiler> Thu Apr 9 21:09:12 GMT [ndmp_session_0]: > ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: > Can't assign requested address > > I can ping destfiler from srcfiler and vice-versa. > The output below shows me that the mover on the destination is still listening for a NDMP data connection to be initiated by the source machine. Obviously the DEC client can see both filers, but perhaps the filers can't see each other on these addresses without a route being added. You can check that all ip addresses are consistent on each machine. I know that I will change the local hosts file on a filer here to talk to a server that the filer knows as server1 (111.222.333.12) whereas the yp map on all other clients will be server1 (222.333.111.70) and server1-333 (111.222.333.12). Alternatively, you could use the -dhost option with NDMPcopy and provide the ip address of the destination filer. You get this value from running ping -s destfiler from srcfiler. BTW, you can generate a bunch of (pretty cryptic) debug by running: rc_toggle_basic ; dbg level ndmpd=0xffff ; rc_toggle_basic. To turn off again run: rc_toggle_basic ; dbg level ndmpd=0x0 ; rc_toggle_basic Hope this helps. Let me know how you get on or if you have any more questions. > > Here's some interesting information: > > srcfiler> ps > [...] > 3687 BR 0% 2160 13% ndmpd > 3688 ?? 0% 3888 11% ndmp_session_0 > 3689 BR 0% 256 0% ndmp_session_1 > 3690 BR 0% 256 0% ndmp_session_2 > 3691 BR 0% 256 0% ndmp_session_3 > 3692 BR 0% 528 1% ndmp_session_4 > [...] > > destfiler> ps > [...] > 3692 ?? 0% 4112 12% ndmp_session_0 > 3693 BR 0% 208 0% ndmp_session_1 > 3694 BR 0% 208 0% ndmp_session_2 > 3695 BR 0% 208 0% ndmp_session_3 > 3696 BR 0% 208 0% ndmp_session_4 > [...] > > srcfiler> ndmpd status > ndmpd ON. > Session: 0 > Active > tape device: not open > data state: Idle > data operation: None > mover state: Idle > > destfiler> ndmpd status > ndmpd ON. > Session: 0 > Active > tape device: not open > data state: Idle > data operation: None > mover state: Listen > > srcfiler> ndmpd probe 0 > ndmpd ON. > Session: 0 > pid: 0xfffffc00006432f0 > isActive: TRUE > eof: FALSE > authorized: TRUE > spt.device_id: -1 > spt.ha: -1 > spt.scsi_id: -1 > spt.scsi_lun: -1 > tape.id: -1 > tape.device: not open > recordCount: 0 > tape.mode: Read only > mover.state: Idle > mover.mode: Read > mover.pauseReason: N/A > mover.haltReason: N/A > mover.dataWritten: 0 > mover.seekPosition: 0 > mover.bytesLeftToRead: 0 > mover.windowOffset: 0 > mover.windowLength: 18446744073709551615 > mover.position: 0 > mover.discardLength: 0 > mover.recordSize: 64512 > mover.recordNum: 0 > mover.rIndex: 0 > mover.wIndex: 0 > data.operation: None > data.state: Idle > data.haltReason: N/A > data.pauseReason: N/A > data.abort: FALSE > data.mover.addr_type TCP > data.mover.addr 0xc0003f0d > data.mover.port 1046 > data.readOffset: 0 > data.readLength: 0 > > destfiler> ndmpd probe 0 > ndmpd ON. > Session: 0 > pid: 0xfffffc00007299f0 > isActive: TRUE > eof: FALSE > authorized: TRUE > spt.device_id: -1 > spt.ha: -1 > spt.scsi_id: -1 > spt.scsi_lun: -1 > tape.id: -1 > tape.device: not open > recordCount: 0 > tape.mode: Read only > mover.state: Listen > mover.mode: Write > mover.pauseReason: N/A > mover.haltReason: N/A > mover.dataWritten: 0 > mover.seekPosition: 0 > mover.bytesLeftToRead: 0 > mover.windowOffset: 0 > mover.windowLength: 18446744073709551615 > mover.position: 0 > mover.discardLength: 0 > mover.recordSize: 64512 > mover.recordNum: 0 > mover.rIndex: 0 > mover.wIndex: 0 > data.operation: None > data.state: Idle > data.haltReason: N/A > data.pauseReason: N/A > data.abort: FALSE > data.mover.addr_type TCP > data.mover.addr 0x0 > data.mover.port 0 > data.readOffset: 0 > data.readLength: 0 > > Any help or ideas would be greatly appreciated. > > Tripp > > Cheers, Grant

1 0

Fun with NDMP
by Tripp Cox 09 Apr '98

09 Apr '98

I have successfully (I think) ported ndmpcopy to Digital Unix, but I am running into some problems trying to initiate a copy. adminhost# ./ndmpcopy srcfiler:/ms/ftp destfiler:/ftp -sa root:passwd -da root:passwd -level 0 -v srcfiler> Thu Apr 9 17:09:12 EDT [ndmp_session_0]: ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: No route to host destfiler> Thu Apr 9 21:09:12 GMT [ndmp_session_0]: ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: Can't assign requested address I can ping destfiler from srcfiler and vice-versa. Here's some interesting information: srcfiler> ps [...] 3687 BR 0% 2160 13% ndmpd 3688 ?? 0% 3888 11% ndmp_session_0 3689 BR 0% 256 0% ndmp_session_1 3690 BR 0% 256 0% ndmp_session_2 3691 BR 0% 256 0% ndmp_session_3 3692 BR 0% 528 1% ndmp_session_4 [...] destfiler> ps [...] 3692 ?? 0% 4112 12% ndmp_session_0 3693 BR 0% 208 0% ndmp_session_1 3694 BR 0% 208 0% ndmp_session_2 3695 BR 0% 208 0% ndmp_session_3 3696 BR 0% 208 0% ndmp_session_4 [...] srcfiler> ndmpd status ndmpd ON. Session: 0 Active tape device: not open data state: Idle data operation: None mover state: Idle destfiler> ndmpd status ndmpd ON. Session: 0 Active tape device: not open data state: Idle data operation: None mover state: Listen srcfiler> ndmpd probe 0 ndmpd ON. Session: 0 pid: 0xfffffc00006432f0 isActive: TRUE eof: FALSE authorized: TRUE spt.device_id: -1 spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.id: -1 tape.device: not open recordCount: 0 tape.mode: Read only mover.state: Idle mover.mode: Read mover.pauseReason: N/A mover.haltReason: N/A mover.dataWritten: 0 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: 0 mover.windowLength: 18446744073709551615 mover.position: 0 mover.discardLength: 0 mover.recordSize: 64512 mover.recordNum: 0 mover.rIndex: 0 mover.wIndex: 0 data.operation: None data.state: Idle data.haltReason: N/A data.pauseReason: N/A data.abort: FALSE data.mover.addr_type TCP data.mover.addr 0xc0003f0d data.mover.port 1046 data.readOffset: 0 data.readLength: 0 destfiler> ndmpd probe 0 ndmpd ON. Session: 0 pid: 0xfffffc00007299f0 isActive: TRUE eof: FALSE authorized: TRUE spt.device_id: -1 spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.id: -1 tape.device: not open recordCount: 0 tape.mode: Read only mover.state: Listen mover.mode: Write mover.pauseReason: N/A mover.haltReason: N/A mover.dataWritten: 0 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: 0 mover.windowLength: 18446744073709551615 mover.position: 0 mover.discardLength: 0 mover.recordSize: 64512 mover.recordNum: 0 mover.rIndex: 0 mover.wIndex: 0 data.operation: None data.state: Idle data.haltReason: N/A data.pauseReason: N/A data.abort: FALSE data.mover.addr_type TCP data.mover.addr 0x0 data.mover.port 0 data.readOffset: 0 data.readLength: 0 Any help or ideas would be greatly appreciated. Tripp

1 0

Re: Backup ; ndmp
by Mark D Simmons 09 Apr '98

09 Apr '98

Now I understand there's quite a bit of work going into backups just now, and I too have a number of questions to add to Philip's: o When is the new, fast backup feature going to be available? o Will it work with NDMP? o Will it work with Networker? o Will it support backups to two concurrent local devices (2xDLT7000 at the same time, for example)? o Can DOT backup to 2 (or more) local devices right now? o Can it do so under NDMP under the control of Netbackup? o Will DOT be able to do backups to multiple local devices concurrently under Networker? o Can an F630 stream two DLT7000's concurrently using any technique you care to name? o Will the new fast backup technology allow for specific-file recoveries or just full-filer-after-disaster recovery? o Are the indexes of NetBackup or Networker maintained on their servers even when backup data is going to locally attached tape drives? o Would this remain possible with concurrent backups as described above? o Does anyone have this sort of aggressive approach to backups already in place? We're looking to breach the TB barrier using 3 F5/600 series machines in the near future and I want to be able to back each filer up no slower than the current longest backup, which is just over 12 hours. Ideally I want to actually cut the backup window and improve our ability to restore data at the same time (because these are worthy goals and because at this time the money seems to be available to do the job 8). > One of our groups is evaluating NetApp for NFS server. > Apparently, their backup concerns are not being satisfactorily addressed > by local NetApp contact. Since backup is a key factor in their > decision, they would appreciate if someone could shed some more > light to their following questions/concerns. > Please feel free to copy the group at: > mannyk(a)msil.sps.mot.com > --------------------------------------------------- > It seems that they have a few select tape drives > that are now able to be connected to the netapps and are recognized > by netbackup. > > The problem I still see and have not recieved a clear answer to is > will ndmp support the tar protocol or just dump? > Does the ndmp protocol support the full dump command - > different levels of dump (incremental, differential and full)? > When and if we will be able to hook up several netapps to one > large tape library unit (STK 9710)? > > What in the ndmp protocol will allow several backup streams > to work simultaneously, so that a full backup of an 800 GB > netapps won't span over several days. > --------------------------------------------------- > > Philip Thomas > Motorola - ATL, M/S M350 > 2200 W. Broadway M350 > Mesa, AZ 85202 > rxjs80(a)email.sps.mot.com > (602) 655-3678 > (602) 655-2285 (fax)

2 1

Re: File Locking
by sirbruce＠ix.netcom.com 08 Apr '98

08 Apr '98

On 04/08/98 11:35:09 you wrote: > >sirbruce wrote: > >> To actually break the locks, you have to log into the filer >> and blow away that user's session. This just seems needlessly >> cumbersome. Assuming most environments have one with root >> access to the filesystem also having access to the filer, >> you are ultimately not "preventing" any behavior... you're >> just making it harder for the administrator. In other words, >> that UNIX rm should result in that CIFS user being logged out >> if need be. > >I think having to take explicit action to terminate a CIFS session is >preferable to blowing it away as a side-effect of a remove. I would worry >about making it too easy to accidently remove something that is in use. I agree with your concerns, but this is exactly why such power is restricted to root. People doing removes as root are already well aware of the dangers of their actions. Removing something in use is already something that has to be faced under NFS, so why do they need additional hand-holding when dealing with a file used via CIFS? Your argument isn't a bad one but it just doesn't fit the paradigm UNIX folks have come to expect. This is just one of many "clashes" between two worlds that will have to be resolved over time. Bruce

1 0

DLT Libraries and Netapps
by Fred Ab 08 Apr '98

08 Apr '98

Looking at purchasing a small (2 drives and 10-15 tapes) DLT library to direct attach to my F520. Please reply with any DLT libraries that you have been really happy with and those that have constant problems / jamming. Don't worry about the software being used to control the unit just the library itself. Thanks in advance for any feedback. Fred. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Fred Abounader Vantis (AMD's PLD Subsidiary) ~ ~ email: fred.abounader(a)vantis.com Mailstop 546 ~ ~ voice: (512)-602-1644 5300 E. Ben White Blvd. ~ ~ FAX: (512)-602-4148 Austin, TX 78741 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters