toasters December 1998

toasters@lists.teaparty.net

32 participants
32 discussions

RE: ClearCase VOBs on NetApp
by Clarke, Bruce 21 Dec '98

21 Dec '98

Network Appliance is working closely with Rational to fully test the procedures and risks for putting the VOB database on the filer. As has been mentioned, putting the various storage pools has always worked and many customers use this to great advantage. Until the move of Network Appliance into the database space, putting the VOB database on the filer was considered risky. Now that both Oracle and Sybase have certified NetApp, it is just a matter of testing, documentation, and time before Rational provides similar certification since theirs is just a modified Raima database anyway. Some discussion on this topic has already taken place on the Clearcase Users Group discussion groups (CCIUG). If you can, I would suggest accessing those archives for the last 2 months to see where this discussion has gone on that forum and get firsthand Rational's response and plans. Bruce Clarke Network Appliance, Inc. -----Original Message----- From: Nick Thompson [mailto:nickthompson@lucent.com] Sent: Friday, December 18, 1998 1:51 AM To: Toasters(a)mathworks.com Subject: ClearCase VOBs on NetApp Hi, We are just starting to deploy ClearCase... I have been speaking to engineers at Network Applications who assured me that it is possible to create the WHOLE of a ClearCase VOB (including the db) on a NetApp filer (and any other NFS filer for that matter). Since Rational told me this was not possible, I got curious and tried it anyway. It worked! Has anybody else here tried this configuration? Had any problems? According to the ClearCase docs, if you can snapshot a complete VOB (as on a Toaster) then it is not necessary to lock it prior to backup (though some disk may be lost to empty containers if you restore from it). Anybody tried/trust this or would you advise against it? Potentially this could make our backup scheme MUCH simpler. Thanks, -- _ _______ __ __ Nick Thompson | Lucent Technologies / \/ / / __\/ // /\ Lucent Technologies | (Bell Labs Innovations) / / / /__/ _ / / Microelectronics House | nickthompson(a)lucent.com /_/\_/_/____/_/\\_\/ Kings Ride, Ascot | Tel: +44 1344 865951 \_\/\\_\____\_\/ \_\ Berkshire SL5 8AD | Fax: +44 1344 865959

1 0

Re: 5.x Restore cannot read 4.x dumps
by Scott Miller 18 Dec '98

18 Dec '98

On Dec 18, 1:01pm, Stephen Manley wrote: > Subject: Re: 5.x Restore cannot read 4.x dumps > > Below is a dialog with our F630 running 5.1.2P1 trying to read a tape written > > with 4.x. We were able to recover data from this tape using a filer running > > 4.3R4D2. > > > > > > range> restore tvf rst0l > > RESTORE: Tape Block size should be 10240, not 64512. > > Fri Dec 18 13:00:12 EST [isp_main]: Tape block was shorter than byte count. Requested = 4096, Read = -50176 > > RESTORE: Could not initialize media. > > range> restore tvfb rst0l 64512 > > RESTORE: No buffers available. > ... > We figured people would get bitten by this change, so we added the error > message (which is obviously not effective) > RESTORE: Tape Block size should be x, not y. > > Now, how do I know the error message didn't work? This message didn't work because it is not obvious. I'd recommend changing the message to somthing like: RESTORE: restore defaulted to a tape block size of 63K RESTORE: your dump was written with a tape block size of 10K RESTORE: re-trying the restore with the block size of 10K ... and then doing the restore with the blocksize that is on the tape. Since you could print the message, you have all the information needed to do The Right Thing (tm) on the users behalf. If I'm doing a restore, it's usually to recover from a disaster. When I'm recovering from a disaster, people are anxious for their data, I'm tired, frustrated and not in the mood to deal with balky restore software. -Skottie -- ----- Scott Miller | Walt Disney Feature Animation skottie(a)fa.disney.com | Digital Studio Technology

1 0

Re: ClearCase VOBs on NetApp
by Keith Brown 18 Dec '98

18 Dec '98

Hi Nick... >I have been speaking to engineers at Network Applications who assured me >that it is possible to create the WHOLE of a ClearCase VOB (including >the db) on a NetApp filer (and any other NFS filer for that matter). I'm afraid I'm not terribly familiar with the ClearCase application myself, but an extensive amount of work on ClearCase interoperability with filer based network storage has been undertaken here at NetApp. So... I just thought I'd call your attention to: http://www.netapp.com/technology/level3/atria.html which documents some of this work. Keith

1 0

Re: 5.x Restore cannot read 4.x dumps
by grdodson＠lexmark.com 18 Dec '98

18 Dec '98

Below is a dialog with our F630 running 5.1.2P1 trying to read a tape written with 4.x. We were able to recover data from this tape using a filer running 4.3R4D2. range> mt -f rst0l diag 1 Fri Dec 18 12:59:45 EST [tape_admin]: Tape driver diagnostic messages enabled. range> mt -f rst0l status Tape drive: Digital DLT7000 Status: ready, write protected Format: 81633 bpi 40 GB (w/comp) fileno = 0 blockno = 0 resid = 0 range> restore tvf rst0l Fri Dec 18 13:00:12 EST [isp_main]: Tape (6.4):cmdblk 0xfffffc0000be7088 op 0x8 block 54272 no error (20 0, 0) RESTORE: Tape Block size should be 10240, not 64512. Fri Dec 18 13:00:12 EST [isp_main]: Tape block was shorter than byte count. Requested = 4096, Read = -50176 Fri Dec 18 13:00:12 EST [isp_main]: Tape (6.4) no sense data. RESTORE: Could not initialize media. range> restore tvfb rst0l 64512 RESTORE: No buffers available. We now have a VERY strong suspicion that tapes written with 4.x cannot be read with 5.1.2P1. Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc. ----- Begin Included Message ----- From stephen%netapp.com(a)interlock.lexmark.com Thu Dec 17 20:24:43 1998 From: stephen%netapp.com(a)interlock.lexmark.com (Stephen Manley) Subject: Re: 5.x Restore cannot read 4.x dumps To: grdodson(a)sol.lpdev.prtdev.lexmark.com Date: Thu, 17 Dec 1998 17:23:54 -0800 (PST) Cc: toasters%mathworks.com(a)interlock.lexmark.com > > > Anyone having problems restoring their dump tapes? We pulled a couple of > old archive tapes (6 mo. old level 0 dumps) to restore some files and were > unable to read them. Kept getting buffer size or buffer allocation errors. > Placed a call to Tech. Sup. waiting for a callback (and waiting, > and waiting, and waiting...). > > While waiting we tried some experiments. The tapes were written on an > F330 running 4.x NFS & CIFS enabled (so we cannot use a sun to restore them). > We discovered that we could read recent tapes written by either an F630 or > F330 on a F630 running 5.1.2P1 with NFS & CIFS. > > I strongly suspect that a filer running 5.1.2P1 cannot read tapes written > with 4.x. This has a less than pleasant affect on our backup & archive strategy. > > Can anyone confirm this? > What's the exact error message? You should be able to restore 4.x tapes on 5.1 systems, and 5.1 tapes on 4.x systems (obviously ACLs disappear) Stephen Manley FS Recovery Superfan ----- End Included Message -----

2 1

Re: 5.x Restore cannot read 4.x dumps
by stephen＠netapp.com 18 Dec '98

18 Dec '98

[Note: I am snipping out the information that is not relevant to the problem. I'm not trying to trick anybody ;)] Executive summary: restore tvfb rst0l 10 will work on 5.1.2P1. > Below is a dialog with our F630 running 5.1.2P1 trying to read a tape written > with 4.x. We were able to recover data from this tape using a filer running > 4.3R4D2. > > > range> restore tvf rst0l > RESTORE: Tape Block size should be 10240, not 64512. > Fri Dec 18 13:00:12 EST [isp_main]: Tape block was shorter than byte count. Requested = 4096, Read = -50176 > RESTORE: Could not initialize media. > range> restore tvfb rst0l 64512 > RESTORE: No buffers available. Ok. This is actually a very simple problem. In every release before 5.1, dump's default tape record size (think 'b' option) was 10KB. In 5.1, we changed this to 63KB. Most people _thought_ the default was always 63KB. It wasn't. So, now, in 5.1, restore _also_ defaults to thinking the tape record size is 63KB. We figured people would get bitten by this change, so we added the error message (which is obviously not effective) RESTORE: Tape Block size should be x, not y. So, if you run your restore as: restore tvfb rst0l 10 you'll be happy with the results. Now, how do I know the error message didn't work? 1) It prints out the tape record sizes in bytes, rather than 1KB blocks. That's fine, except that the command line wants the numbers in 1KB blocks. This will be changed for the next release. I apologize for this. Anyway, in your second test, restore is saying it can't grab 64512*1024 bytes. This isn't particularly surprising. Since most people don't use a 64MB tape record size, restore can't really hande that. Again, this is our fault for printing out the wrong increment. 2) You seem to have chosen to use the number that restore said was a bad record size (i.e. 63KB). We need to make sure people try to use the 10KB. We'll try to re-examine how to make that part of the message clearer as soon as we can. In summary, dump/restore should be both _forward_ and _backward_ compatible, as well as ufsrestore compatible. If this ever changes, we will make sure everybody knows this. Thanks for your patience, Stephen Manley FS Recovery Tenor

1 0

Re: 5.x Restore cannot read 4.x dumps
by Fred Ab 18 Dec '98

18 Dec '98

---} We now have a VERY strong suspicion that tapes written with 4.x cannot be read ---}with 5.1.2P1. I have a F220 running 4.3.3 and a F540 running 5.0.1. I just wrote a tape on the F220 using dump on a local attached DLT-4000 using compression. I then took the tape out and put it in a DLT-7000 that is locally attached to the F540. I had no problem doing a listing of the tape: america> mt -f nrst1a rewind america> restore tvf nrst1a Verify tape and initialize maps Tape block size is 63 Dump date: Fri Dec 11 23:52:14 CST 1998 Dumped from: the epoch Level 0 dump of /etc on mach5svr:snapshot_for_dump.116 Label: none Extract directories from tape Initialize symbol table. dir 2 . leaf 1106080 ./messages leaf 100277 ./rc dir 100263 ./crash I then went to a Sun Solaris 2.6 node and did a remote restore of a single file from the same tape. Therefore, it isn't true that "5.x Restore cannot read 4.x dumps" however there still might be a problem with 5.1.2P1 reading the 4.x version. I am very interested in the resolution of your problem because I plan on upgrading the 4.3.3 to one of the newer 5.x releases next week. One that is "Y2K Compatible" and I'm wondering now if I'll see the same problem. 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 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: ClearCase VOBs on NetApp
by Scott Miller 18 Dec '98

18 Dec '98

On Dec 18, 9:50am, Nick Thompson wrote: > Subject: ClearCase VOBs on NetApp > I have been speaking to engineers at Network Applications who assured me you mean Network Appliance, right? > that it is possible to create the WHOLE of a ClearCase VOB (including > the db) on a NetApp filer (and any other NFS filer for that matter). > Since Rational told me this was not possible, I got curious and tried it > anyway. It worked! Has anybody else here tried this configuration? Had > any problems? Not the VOB itself. Text pools, DO pools, etc work great on a NetApp, but the VOB (I always thought) needed to be on disk that was physicially local to the VOB server. take a look at http://www.netapp.com/technology/level3/atria.html for NetApp's version of how to use their filers with Atria. > According to the ClearCase docs, if you can snapshot a complete VOB (as > on a Toaster) then it is not necessary to lock it prior to backup You still want to lock the VOB, take the snapshot, then unlock the VOB before the backup. Since a VOB is a database, if you don't lock it you might get an inconsistant copy of the VOB in the snapshot. > (though some disk may be lost to empty containers if you restore from > it). Anybody tried/trust this or would you advise against it? Our backups work kind of like this. We lock all the VOBS, make a snapshot using Veritas FileSysteM snapshots, unlock the VOB, then backup the snapshot. Same concept, same benefits: backup doesn't lock the VOB for very long, which means developers aren't impacted. -Skottie -- ----- Scott Miller | Walt Disney Feature Animation skottie(a)fa.disney.com | Digital Studio Technology

1 0

Re: Routing Anomaly..
by Keith Brown 18 Dec '98

18 Dec '98

> >Im assuming that the default route on the filer is being used to send out >traffic destined for 151.142.223.0/24. Not on a good day it won't! :-) The filer's networking code should be more than sharp enough to see that it has an interface directly connected to your 151.142.223.0 network and route packets targeted to this network to said interface accordingly. In fact, a "netstat -r" on the console should show you an explicit zero-metric route for each network, directing traffic to the interface on which that network is to be found (look for gateway targets that look like "link#1", "link#2" in the "Gateway" column). >What should I do to make the e1a interface active to the 151.142.223.0/24 >network? I read your e-mail twice and can't spot a configuration mistake. Everything looked fine in fact. Is it possible that there is a more fundamental problem? A bad cable connecting the filer to the switch? A VLAN configuration within the switch that is preventing the filer's port from communicating with the Sun ports? A complete examination of the routing tables on filer, Suns and Cisco might reveal something peculiar. As an act of desperation, bringing the filer up without the FDDI interface configured (such that it is no more than a single Ethernet interface system connected via a switch to three other single Ethernet interface systems) might also be an experiment worthy of a shot. Keith

2 2

5.x Restore cannot read 4.x dumps
by grdodson＠lexmark.com 18 Dec '98

18 Dec '98

Anyone having problems restoring their dump tapes? We pulled a couple of old archive tapes (6 mo. old level 0 dumps) to restore some files and were unable to read them. Kept getting buffer size or buffer allocation errors. Placed a call to Tech. Sup. waiting for a callback (and waiting, and waiting, and waiting...). While waiting we tried some experiments. The tapes were written on an F330 running 4.x NFS & CIFS enabled (so we cannot use a sun to restore them). We discovered that we could read recent tapes written by either an F630 or F330 on a F630 running 5.1.2P1 with NFS & CIFS. I strongly suspect that a filer running 5.1.2P1 cannot read tapes written with 4.x. This has a less than pleasant affect on our backup & archive strategy. Can anyone confirm this? Thanks. Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc.

3 2

ClearCase VOBs on NetApp
by Nick Thompson 18 Dec '98

18 Dec '98

Hi, We are just starting to deploy ClearCase... I have been speaking to engineers at Network Applications who assured me that it is possible to create the WHOLE of a ClearCase VOB (including the db) on a NetApp filer (and any other NFS filer for that matter). Since Rational told me this was not possible, I got curious and tried it anyway. It worked! Has anybody else here tried this configuration? Had any problems? According to the ClearCase docs, if you can snapshot a complete VOB (as on a Toaster) then it is not necessary to lock it prior to backup (though some disk may be lost to empty containers if you restore from it). Anybody tried/trust this or would you advise against it? Potentially this could make our backup scheme MUCH simpler. Thanks, -- _ _______ __ __ Nick Thompson | Lucent Technologies / \/ / / __\/ // /\ Lucent Technologies | (Bell Labs Innovations) / / / /__/ _ / / Microelectronics House | nickthompson(a)lucent.com /_/\_/_/____/_/\\_\/ Kings Ride, Ascot | Tel: +44 1344 865951 \_\/\\_\____\_\/ \_\ Berkshire SL5 8AD | Fax: +44 1344 865959

1 0

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 December 1998