toasters

toasters@lists.teaparty.net

13531 discussions

DELL<->NetApp deal?
by Philip Thomas 28 Feb '99

28 Feb '99

Can NetApp provide some more details on this DELL <->NetApp announcement? http://www.dell.com/corporate/media/newsreleases/98/9811/04.htm http://www.netapp.com/news/level3b/news_rel_981104.html (a) Are they going to take say, a 740 stick Dell label on it and sell? (b) Is this going to replace Dell's disk subsystem? In which case the NetApp/disks are no longer a "network attached" system. Am I right? (c) Will this NetApp disk system from Dell loose any of NetApp's features, namely '.snapshot'.? (d) I would assume Dell system; no speak NFS?? Philip Thomas Motorola - PEL, 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: DELL<->NetApp deal?
by Melvin, Grant 27 Feb '99

27 Feb '99

(d) I would assume Dell system; no speak NFS?? Yip, one of the reasons that we are producing papers such as "How to Integrate a Network Appliance Filer into the Windows NT Backup Model". Check it out at: http://www.netapp.com/technology/level3/3052.html Cheers, Grant

1 0

Re: Problems w/ NetApp & BudTool 4.6
by Jason D. Kelleher 26 Feb '99

26 Feb '99

In message <36D6915F.EA2416A6(a)iguard.com>, James Lowe writes: >Would anyone from Network Appliance care to comment on anything about >this thread? > >Yours waiting in anticipation > >James Lowe >Intelliguard Software International I'm not from NetApp, but I'd love to comment... We recently (Saturday) upgraded from BudTool 4.5 to 4.6. After Shona told us to check the jbcap file (care to comment why AFTER 6 DAYS NO ONE AT INTELLIGUARD HAD HELPED US!!!), so BudTool 4.6 could control the jukebox on our filer we have the following systems running: BudTool 4.6 SunOS 4.1.3_U1, Solaris 2.5.1, 2.6, & 2.7 OnTap 5.1.2R3P1 (recommended by NetApp support) The NetApp is working great. The only problems we're currently having regard errors in the btmerge reports: ============================================= ============================================= Running btmerge for host hercules.dev.susq.com Command: (btmerge -s / -o /audreyii/budtool/hist/hercules.dev.susq.com/db.hercules.dev.susq.com.n.of.m.tm p -m /audreyii/budtool/hist/hercules.dev.susq.com/db.hercules.dev.susq.com.n.of.m -H hercules.dev.susq.com -c /usr/budtool/bud/.budfclass -i /usr/budtool/hist/db.hercules.dev.susq.com -i /usr/budtool/build/db.her cules.dev.susq.com.int.0) ****************************************************************** ------ E R R O R ------- Cannot get maximum file history database continuation number: (Error 0) ****************************************************************** ****************************************************************** ------ E R R O R ------- A btmerge input file was busy. Rebuilding list of input files. ****************************************************************** ============================================= ============================================= These are refering to a Solaris 2.6 system with a FQDN in the .buddb. After removing all FQDNs from our .buddb, everything worked fine. So, I think you should quite pointing fingers at NetApp and FIX THE PROBLEM! jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Partners, G.P. 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122 >Shona McNeill wrote: >> >> "Shaun T. Erickson" <ste(a)research.bell-labs.com> writes: >> > >> > When I upgraded to BudTool 4.6, my file history database merges failed >> > too, except for one system. That one system's name was not fully >> > qualified, so it's merges worked. All the merges failed for systems wit >h >> > fully qualified host names. This is as seen in $BTHOME/hist. First, a >> > patch to BudTool's patch program was required. Then, they gave me a "on >e >> > off" patch, to make the merges work. It did, except that when my >> > toaster's database was converted to the 4.6 format and the saved up fil >e >> > histories were merged in, the size grew past 500MB and the database for >> > that system split in two. So far so good. Then that system's file >> > history merges failed again, this time because the continuation file ha >d >> > a bad magic number. >> > >> >> We have just installed BudTool 4.6 from scratch, hosted on a Sun running >> Solaris 7, backing up one of our newly-installed NetApps, all of which >> shipped running 5.1.2R3. >> >> Once we'd fixed the jbcap file and could actually talk to the jukebox, we >> found that history merges fail with msrt coredumping. >> >> We _are_ using FQDNs, but then this one copy of BudTool will be eventuall >y >> controlling backups for NetApps in different subdomains, so not using FQD >Ns >> is not really an option here. >> >> Iguard have mentioned nothing of patches, their answer is for us to upgra >de >> the filer to 5.2.1 as "BudTool is certified against that version". >> (We refused their first suggestion to downgrade the filer to 5.1.2P2.) >> >> I am loathe to schedule downtime on a busy filer for what may prove an >> unnecessary upgrade. Is there anyone out there using BudTool 4.6 with fi >le >> histories _and_ FQDNs _and_ a filer running 5.2.1 who can comment on whet >her >> this upgrade will have any effect on the problem whatsoever? >> >> Shona McNeill >> -- >> shona(a)netline.net.uk

3 2

Re: Problems w/ NetApp & BudTool 4.6
by Jason D. Kelleher 26 Feb '99

26 Feb '99

James, Ummm.... I'm a bit confused... You responded to me, or so it seems, but many of the snipets of text you referred to in the first half of your message aren't from me, or the message I sent...? And I beleive we were discussing the problem of btmerge failing for systems with FQDNs. I know nothing about the "one off" patch for merges. Not surprising since it took tech support 3 days to inform us about the "one off" for the btcp failures we reported on Saturday... The text reffering to the "one off" patch was nowhere in the message I sent. I didn't complain about any "KNOWN PROBLEM WITH THE ONTAP OS PRIOR TO 5.1.2P2". We aren't running OnTap version prior to 5.1.2P2... Who were you responding to...? As for having to wait 6 days... We did call Intelliguard several times a day, only to be put through to voice mail. These messages were rarely returned. I spent 4 hours trying to get in touch with support personnel Monday (after I got tired of waiting for a call back from Sunday). After leaving several voice mails I decided to try and speak to a manager, I was told they were busy and asked if I'd like to leave them voice mail.... The only human being working for Inelliguard I could get a hold of was our regional sales rep and it took him another hour to get someone to call me (17:00 EDT)... Would you like further explanation for my "rude, arrogant, & cynical attitude"...? Forgive me, but I beleive I'm very polite the first 2-3 times I call tech support regarding an issue. I start getting sarcastic around the 4th call and rude around the 6th call for any specific problem. I've been told I need to work on my patience. Notice, I'm not complaining about your attitude. While working, I could care less what someone's attitude is as long as they get the job done. I go home to be around nice people. At work I expect people to do their jobs... By the way, I'm still trying to find out what the expected response time for a call to Intelliguard 24x7 support is...? (You know, that service that you charge extra for...) If I'm told it's 4 or more hours, I'll gladly apologize and expect less in the future. You are correct that the version of OnTap, 5.1.2R3P1, we are running is not officially certified by NetApp & BudTool. I'm sorry if my message implied that it was. I meant to point out the fact that this combination of OnTap & BudTool has no btmerge problems as long as no FQDNs are used. Oh well, we are currently not having any problems with BudTool 4.6. Intelliguard support fixed our btcp problem, Shona fixed our jbcap problem, and the various people discussing the FQDN issues took care of that for us. If I'm lucky, I won't need to speak to Intelliguard until I have to get new keys for some jukebox licenses and I think that can be done via email. have a good weekend, jason P.S. I'll now refrain from commenting on BudTool, I'm starting to take this too personally -- understandable since I've spent more time with BudTool than my girlfriend this week.... In message <36D70609.22997A9A(a)iguard.com>, James Lowe writes: >errr..sorry Mr Kellerher, I thought the problem that we were discussing >was core dumps from BudTool due to 'bad' Filehistory streams from the >filers found by the NetApp tech team and resolved in the P2 patch of >5.1.2P2. > >> >> >First, a >> >> > patch to BudTool's patch program was required. > >Oh dear me..software that needs patches...now that is unheard of isn't >it? > >> >>Then, they gave me a "one >> >> > off" patch, to make the merges work. It did, > >Patches that work?..my oh my..whatever next > >> >>except that when my >> >> > toaster's database was converted to the 4.6 format and the saved up >fil >> >e >> >> > histories were merged in, the size grew past 500MB and the database >for >> >> > that system split in two. So far so good. Then that system's file >> >> > history merges failed again, this time because the continuation file > ha >> >d >> >> > a bad magic number. > >..and guess what...this is a KNOWN PROBLEM WITH THE ONTAP OS PRIOR TO >5.1.2P2 > >And if you are really really lucky you might see all the CPU sucked out >of your BudTool machine by BudTool's merge binaries as it tries to >negotiate 'bad' filehistory datastreams from the filer. You can watch >your network grind to a halt as your NFS falls over and see your >precious disk space fill up with a lovely juicy core file fresh from the >MSRT oven. > >Now that was us producing the core file we have never denied that, but >instead of..as you so elegantly put it...let me see.. > >ah yes.. > >> So, I think you should quite pointing fingers at >> NetApp and FIX THE PROBLEM! > >We didn't point fingers oh no...through what is known as 'cooperation' >and being 'proactive' Intelliguard AND Network Appliance worked on it... >and you know what? 5.1.2'P2' was produced but nothing was needed for >BudTool note. You see NDMP is a 'joint' effort (not just with >Intelliguard and NetApp I might add) And you know what else? We did the >same with NetApp for 5.1.2..we worked together and now we are working >towards OnTap 5.3...now I don't know exact figures, but i reckon that >between 5.0.1 and 5.1.2 there have been a few dozen P and R and D (and >whatever else letters you care to use) patches for OnTap, some of them >making quite significant changes to the filer I believe and some of them >out less than 24 hours after the previous ones. If ANY software company >could test against all these different versions in such a short space of >time I would be very impressed. Indeed some of these extra patches from >NetApp were to fix bugs in previous patches a days earlier. > >As far as I am aware (and you will need to verify with NetApp about this >I suppose as you obviously have no time for Intelliguard). This release >of OnTap that you have been recommended by NetApp has not been certified >(as far as I, or any of the team in Europe have been informed anyway) >against BudTool 4.6. So far be it for me to start advising people to >upgrade to *Operating systems* that may or may not work with our >product. > >You may not care about any of this, and just want a fix, fair enough. >However, before you start 'spouting off' at people like myself who do >try and genuinely help as much as we possibly can can I point out one >last thing please... > >> (care to comment why AFTER 6 >> > DAYS NO ONE AT INTELLIGUARD HAD HELPED US!!!) > >I won't defend genuinely poor 'support' from Intelliguard ever, >especially if you have paid for the maintenance, however why did you >have to wait 6 days anyway? If the problem was so urgent as you have >blatantly made obvious it was, why were you not on the phone, email >bombarding the support team until you had your answer?, getting cynical, >rude and arrogant as you do so well on this mailing list and even ask to >be put on hold until a 'manager' was made available to you? You may say >you shouldn;t have to, and I would agree whole heartedly...but life's >funny like that jason...sometimes it lets you down.. > >Have a good weekend > >James Lowe >Intelliguard Software International > >Jason D. Kelleher wrote: >> >> In message <36D6915F.EA2416A6(a)iguard.com>, James Lowe writes: >> >Would anyone from Network Appliance care to comment on anything about >> >this thread? >> > >> >Yours waiting in anticipation >> > >> >James Lowe >> >Intelliguard Software International >> >> I'm not from NetApp, but I'd love to comment... >> >> We recently (Saturday) upgraded from BudTool 4.5 to 4.6. After >> Shona told us to check the jbcap file (care to comment why AFTER 6 >> DAYS NO ONE AT INTELLIGUARD HAD HELPED US!!!), so BudTool 4.6 could >> control the jukebox on our filer we have the following systems >> running: >> >> BudTool 4.6 >> >> SunOS 4.1.3_U1, Solaris 2.5.1, 2.6, & 2.7 >> >> OnTap 5.1.2R3P1 (recommended by NetApp support) >> >> The NetApp is working great. >> >> The only problems we're currently having regard errors in the >> btmerge reports: >> >> ============================================= >> ============================================= >> Running btmerge for host hercules.dev.susq.com >> >> Command: (btmerge -s / -o /audreyii/budtool/hist/hercules.dev.susq.com/d >b.hercules.dev.susq.com.n.of.m.tm >> p -m /audreyii/budtool/hist/hercules.dev.susq.com/db.hercules.dev.susq.co >m.n.of.m -H hercules.dev.susq.com >> -c /usr/budtool/bud/.budfclass -i /usr/budtool/hist/db.hercules.dev.susq >.com -i /usr/budtool/build/db.her >> cules.dev.susq.com.int.0) >> >> ****************************************************************** >> ------ E R R O R ------- >> Cannot get maximum file history database continuation number: (Error 0) >> ****************************************************************** >> ****************************************************************** >> ------ E R R O R ------- >> A btmerge input file was busy. >> Rebuilding list of input files. >> ****************************************************************** >> ============================================= >> ============================================= >> >> These are refering to a Solaris 2.6 system with a FQDN in the >> .buddb. After removing all FQDNs from our .buddb, everything >> worked fine. So, I think you should quite pointing fingers at >> NetApp and FIX THE PROBLEM! >> >> jason >> >> --- >> Jason D. Kelleher kelleher(a)susq.com >> Susquehanna Partners, G.P. 610.617.2721 (voice) >> 401 City Line Ave, Suite 220 610.617.2916 (fax) >> Bala Cynwyd, PA 19004-1122 >> >> >Shona McNeill wrote: >> >> >> >> "Shaun T. Erickson" <ste(a)research.bell-labs.com> writes: >> >> > >> >> > When I upgraded to BudTool 4.6, my file history database merges fail >ed >> >> > too, except for one system. That one system's name was not fully >> >> > qualified, so it's merges worked. All the merges failed for systems >wit >> >h >> >> > fully qualified host names. This is as seen in $BTHOME/hist. First, >a >> >> > patch to BudTool's patch program was required. Then, they gave me a >"on >> >e >> >> > off" patch, to make the merges work. It did, except that when my >> >> > toaster's database was converted to the 4.6 format and the saved up >fil >> >e >> >> > histories were merged in, the size grew past 500MB and the database >for >> >> > that system split in two. So far so good. Then that system's file >> >> > history merges failed again, this time because the continuation file > ha >> >d >> >> > a bad magic number. >> >> > >> >> >> >> We have just installed BudTool 4.6 from scratch, hosted on a Sun runni >ng >> >> Solaris 7, backing up one of our newly-installed NetApps, all of which >> >> shipped running 5.1.2R3. >> >> >> >> Once we'd fixed the jbcap file and could actually talk to the jukebox, > we >> >> found that history merges fail with msrt coredumping. >> >> >> >> We _are_ using FQDNs, but then this one copy of BudTool will be eventu >all >> >y >> >> controlling backups for NetApps in different subdomains, so not using >FQD >> >Ns >> >> is not really an option here. >> >> >> >> Iguard have mentioned nothing of patches, their answer is for us to up >gra > >de >> >> the filer to 5.2.1 as "BudTool is certified against that version". >> >> (We refused their first suggestion to downgrade the filer to 5.1.2P2.) >> >> >> >> I am loathe to schedule downtime on a busy filer for what may prove an >> >> unnecessary upgrade. Is there anyone out there using BudTool 4.6 with > fi >> >le >> >> histories _and_ FQDNs _and_ a filer running 5.2.1 who can comment on w >het >> >her >> >> this upgrade will have any effect on the problem whatsoever? >> >> >> >> Shona McNeill >> >> -- >> >> shona(a)netline.net.uk

1 0

Nitech XRP1000 filer
by Brian Tao 26 Feb '99

26 Feb '99

Has anyone used the XRP 1000? It's Nitech's "answer" to the Netapp (the even mention Network Appliance specifically as the market leader in network-attached storage, and that they compete with Netapp). http://www.nitech.com/online/Company/Storage/XRP_1000/body_xrp_1000.html -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

9 12

Re: Problems w/ NetApp & BudTool 4.6
by James Lowe 26 Feb '99

26 Feb '99

Mr Blank-Edelman, et al, I am so sorry, this is not the patch. It has been one of those months for me.. %^& I should not be so quick to jump in I suppose. My apologies for wasting your time. Yours, eating humble pie James Lowe Intelliguard Software International David N. Blank-Edelman wrote: > > James Lowe <jlowe(a)iguard.com> writes: > > > ftp.iguard.com/pub/dist/patch/BudTool/BudTool46/BudTool46-3 > > Sorry, which does what? Is a new patch? The others we tried a while > back did not allow for successful merges. We're ok with not using a > FDQN now, but it was problematic when we first tried to use your > product. > > Respectfully, > David N. Blank-Edelman > Director of Technology > College of Computer Science > Northeastern University

3 3

Re: DELL<->NetApp deal?
by mds＠gbnet.net 26 Feb '99

26 Feb '99

I was amused by the way The Register misreported the NetApp-Dell deal with the spin on Dell selling Alpha-based systems not running NT... Though they did get the NetApp URL right so the nae may spread further.

1 0

RE: Auspex 4Front presentation.
by Thomson, Michael (UK, GIS ISM Group for R&D) 26 Feb '99

26 Feb '99

The presentation was mainly just marketing waffle, with some humble grovelling. We did get to put hands on teh new products, which look cool, but the big NS2000 doesn't come as a rack mount option - it's a stacking arrangement only for now. Auspex seemed to be saying that they've dropped their prices and replaced their management team to turn round from the recent trouble (see share price graphs on yahoo if you haven't been following the saga). They are refocusing themselves <eek - pointy haired management term> on software, and moving off proprietary hardware. All this sounds encouraging (competition is good). Cheers, Mike

1 0

Re: Gigabit Ethernet controller.
by Andrew Bond 26 Feb '99

26 Feb '99

Dan, I don't know what the default setting on a Cisco Gbit blade is, but I had a similar experience this week on a 3Com switch. If autonegotiation is enabled on the switch port, either turn it off at the switch (preferred), or turn it on at the filer end: rc_toggle_basic; alttune LinkNegotiation 1; rc_toggle_basic You may find the card bursts into life :) If you use this command, you'll need to put it in the rc file (after the ifconfig for the Gbit NIC). Regards, Andrew At 06:37 AM 2/26/99 -0800, you wrote: >Support, > >I recently received an F740 S/N 11918 with a gigabit Ethernet controller. I >am running 5.2.1 DataONTAP. I had it configured into rc but when the system >boots the link light just flashes. The connection is going to gigabit >module on a Cisco Catalyst 5500 switch the link light on that side does >nothing. I spoke to Cisco and they wanted to know if the Ethernet card was >using the 803.Z standard. > > Dan Arteritano, FileNET, Central Computer Facilities - Engineering, > HT1 Office 110 > Email: darteritano(a)filenet.com, Phone: 714/966-3130 > Pager: (800) 341-9652 or email to 3419652(a)skytel.com >

1 0

Re: Problems w/ NetApp & BudTool 4.6
by dnb＠ccs.neu.edu 26 Feb '99

26 Feb '99

"Shaun T. Erickson" <ste(a)research.bell-labs.com> writes: > All the merges failed for systems with fully qualified host names. Yup, same problem here (complete with the same Iguard runaround). We "solved" it by telling budtool not to use the FDQN. bah. Peace, dNb

3 2

Re: Problems w/ NetApp & BudTool 4.6
by Jason D. Kelleher 26 Feb '99

26 Feb '99

IT WORKS!!! Special thanks to: Tom Wike for verifying that BudTool 4.6 actually does work with OnTap 5.1.2R3P1 despite some confusing/conflicting recomendations from both NetApp and Intelliguard. Bamiyan Gobets & Grant Schuerfeld from NetApp for verifying all our configs. And finally to Shona McNeill who experienced the same problems and told me to check our jbcap file. After copying the entry for our jukebox from the old jbcap into the new, everything worked great! If any of you make it to the Philadelphia area, drop me a note so I can buy you a beer. No thanks to: Intelliguard support... :( Unfortunately, we just noticed that the file history database merges are not working properly. Hopefully we can resolve this ourselves, 'cause Intelliguard isn't any help.... Thanks again to everyone who provided help. jason In message <199902241959.OAA28405(a)jagular.dev.susq.com>, "Jason D. Kelleher" writes: > > On the evening of Saturday February 20 we upgraded from BudTool 4.5 > to 4.6. Since then, we've not been able to do local NDMP backups > on our filer. Anyone out there experience similar problems? If > so, would you please throw some suggestions my way. > > We have support calls open with both NetApp (being very helpful > considering it's probably not an issue with their system) and > Intelliguard (with what we pay them I'd assume they could at least > hire warm bodies). Here's what we've come up with so far: > > > 1) Intelliguard told us to add the line "ROBOT_SCSI_LUN 1" to > the jbmgr_config for the filer. This allowed the jbmgr > daemon to start. > >audreyii: /usr/budtool/bud [225] % cat jbmgr_config.audreyii.2 >ROBOT_DEV_HOST nfssrv1 >ROBOT_DEV_NAME spt0 >ROBOT_SCSI_ID 2 >ROBOT_SCSI_BUS 2 >ROBOT_SCSI_LUN 1 >DATA_DEV_NAME0 nrst0a >DATA_DEV_HOST0 nfssrv1 >PASSWORD xxxxxxxx >USEBARCODE N >VALIDATECMD "$BTHOME/bin/jbupdate audreyii:2 -a" >audreyii: /usr/budtool/bud [226] % > > > 2) Running the BudTool probe-scsi command shows the devices: > >audreyii: ~ [230] % probe-scsi -h nfssrv1 >Copyright (c) 1990-1999 by Intelliguard Software Inc. probe-scsi BudTool 4. >6 >SCSI Bus 0 >SCSI Bus 1 >SCSI Bus 2 >Target 2 > Unit 0 Removable Tape EXABYTE EXB-8500 CC37 > Unit 1 Removable Jukebox Device EXABYTE TZ Media Changer CC37 >SCSI Bus 3 >SCSI Bus 4 >audreyii: ~ [231] % > > > 3) After placing 2 labled BudToool tapes into the jukebox, > running jbupdate returns instantly showing no tapes in the > jukebox (doesn't even attempt to read tape labels). > >audreyii: ~ [236] % jbupdate audreyii:2 -a >------------------------------------------------------------------ > ------ W A R N I N G ------- >You have selected to force an update on all 5 tapes. This process >requires several minutes per tape for unbarcoded tapes. Large >jukeboxes with unbarcoded tapes can take several hours. The PID of >this process is 8721. Use a HUP, INT, TERM or QUIT to terminate >this process if you do not want to continue. >------------------------------------------------------------------ >Update complete. >audreyii: ~ [237] % jbmgr -H audreyii:2 ls -a > 0: > 1: > 2: > 3: > 4: >audreyii: ~ [238] % > > > 4) We can perform remote NDMP backups to our BudTool master > media server, but this isn't practical at ~2.2 GB/hr with > 70+ GB on our filer. (It's an old, slow F330 which I'm > supposed to be replacing instead of trouble-shooting...) > > 5) Gave Intelliguard a copy of our config file, the jbmgr diag > log, and the probe-scsi output for analysis. The diag file > does show some errors: > > 6) After not receiving much help from Intelliguard, we called > NetApp. They sugggested we upgrade from 5.1.2P2 to > 5.1.2R3P1 to remove the possibility that this was related to > an NDMPD bug (6417). > > 7) Spoke to Intelliguard again Monday and informed them that we > were going to upgrade the filer. We decided to see if the > upgrade solved the problem. (They managed to fix a btcp > issue after I waited 4 hours for a call back -- I'm still > waiting for our sales rep to tell me exactly what kind of > turn around to expect when paying extra for 24x7 support.) > > 8) Nothing changed after the upgrade Monday night. I informed > NetApp; they opened another call and had us send them more > info. > > 9) Told Intelliguard, gave them another copy of the diag file. > > 10) Configured BudTool to do lev 1 remote backups of the filer, > this should hold us until the weekend. > > 11) Had to take a personal day Tuesday (for personal reasons). > Hoped I get a couple voice/e-mails telling me that someone > figured out what was wrong. (Finding out we were stupid > and didn't have BudTool configured correctly would have > been a relief.) > > 12) Wednesday we received some follow-up calls from NetApp, the > call was escalated, and we're currently expecting a call. > > 13) We verified that tapes can be manually loaded into the > jukebox drive and dump run on the console of the filer. > Pretty confident that the jukebox didn't coincidentally die > during the BudTool upgrade. > > 14) Will file missing persons reports for Intelliguard > employees in another 24 hours. (Anyone have the number for > the police in Dublin, CA?) > > > So far, I'm confident it's a BudTool issue. (Many thanks/apologies > to NetApp if it is.) I'd be very grateful if someone could give me > a possible avenue of investigation. I'm at a dead-end and looking > at over 30 hours of backups to lev 0 our filer this weekend... :( > > thanks, > > jason > >--- >Jason D. Kelleher kelleher(a)susq.com >Susquehanna Partners, G.P. 610.617.2721 (voice) >401 City Line Ave, Suite 220 610.617.2916 (fax) >Bala Cynwyd, PA 19004-1122

4 3

RE: Nitech XRP1000 filer
by Thomson, Michael (UK, GIS ISM Group for R&D) 26 Feb '99

26 Feb '99

>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> >> To open a real can-of-worms, what would people on this list like to see in >> a low-end product offering? (Sub-$10k chassis). >This hypothetical discussion would be of great interest to me. :-) A bit like the Auspex 4Front AS100 / AS200 perchance? I just attended a presentation in London, and it looks like they've finally woken up to the low end of the market. Having used & administered Auspex and NetApp personally, it'll be interesting to see what happens in the next year... -- \\|||// Minds are like parachutes; (@ @) They only work when open. *---oOO-(_)-OOo------------------------------------* * Michael Thomson Email: mt53590(a)ggr.co.uk * * Unix Specialist Internal: 782 2369 * * Glaxo Wellcome External: 01438 762 369 * * Stevenage, UK Fax: 01438 762 461 * * .oooO Oooo. Mobile: 0498 725 047 * *--( )---( )-----------------------------------* \ ( ) / (Quote: Sir James Dewar) \_) (_/

2 1

Net App and NetBackup
by Michael Salmon 26 Feb '99

26 Feb '99

I wondered if anyone was using NetBackup with their filers. We are currently using Networker but are sufficiently dissatisfied that we going to look at NetBackup and I am interested in any problem that others have encountered. /Michael

7 8

Re: Nitech XRP1000 filer
by sirbruce＠ix.netcom.com 26 Feb '99

26 Feb '99

On 02/25/99 08:34:50 you wrote: > > > >>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> > >>> To open a real can-of-worms, what would people on this list like to see in >>> a low-end product offering? (Sub-$10k chassis). > >>This hypothetical discussion would be of great interest to me. :-) > >I'll take a crack at it: > >PC-ish Mini-tower not to exceed 19" high (so it could be rack mounted on its side) >Lower-end Alpha or medium Intel processor (whatever's cheaper for NetApp) >256 MB RAM >4-8MB NVRAM >Single 10/100 Ethernet >Single SCSI Bus >Up to 7 9GB (or larger?) disks >A couple of PCI slots for other types of network interfaces, and/or SCSI Tape. > >Make it one box, disks and all. I thought they already did this. It was called the F210. :) My personal experience with those admins who are "cheap" either by nature or by force is that such a small box doesn't appeal to them for a variety of reasons. They don't need high-performance at that end of the scale, so they can cobble together a server with cheaper ethernet cards and disks that work "just as well". They may not get RAID, but they rarely need it. Then the inevitable happens... they want to add more disk that it can take. They feel resentful that they can't add more disk, even though they think the CPU can handle it. The have no qualms about stringing 21 drives off an old Pentium with an ISA ethernet card if they can get away with it. And of course they want to use *their* cheap disk, not what Netapp wants for the performance. And then when the load gets too great or it crashes, they want to blame the vendor(s) and netapp. And then they get resentful if you tell them they have to upgrade the whole server to handle the increased load of the increased disk and users... they want to just put in more memory, or swap the CPU, and be done with it! I'm not saying Netapp can't make some more inroads into the low-end. I think they can and will, eventually. But there's a large contigent out there who always think they can get away with doing it cheaper by putting together their own linux box with a bunch of disks. Sometimes they can get away with it; sometimes they can't. If netapp can design a low-end box that uses cheaper components and perhaps has optional RAID but still at reasonable (not great) performance, they might be able to make some headway. But the margin will be small. Bruce

3 2

atime updates - OT 5.1.1 / NFS / FreeBSD
by Brett Rabe 26 Feb '99

26 Feb '99

Greetings. Is it the correct NFS behavior for non-uid-0 users opendir() calls to not update st.st_atime, but uid-0 opendir() calls to do so? I've got a filesystem mounted from the NetApp to the FreeBSD machine, exported as: /vol/vol0/home -access=client_hostname,anon=0 It's mounted on the client rw,intr,nfsv2. When I run a program as uid 0 that does simply an opendir()/closedir() on a directory, the directory's st.st_atime gets updated. When I run the same program as uid > 0 (in this case, 51, to be exact), atime does not get updated. I'm obviously missing my NFS roll here. Whassup with that? Shouldn't client requests as non-uid 0 also update atime? (Because I know somebody will ask, no_atime_update is not set on the volume. :) ) Am I just plain not understanding the man pages? Brett --- Brett Rabe Email : brett(a)uswest.net Systems Administrator - U S West Phone : 612.664.3078 Interact - 3S Pager : 612.613.2549 600 Stinson Blvd. Fax : 612.664.4770 Minneapolis, MN 55413 USA Pager : page-brett(a)uswest.net Bombs don't kill people. Explosions kill people.

2 2

Re: Nitech XRP1000 filer
by Tony Paolucci 25 Feb '99

25 Feb '99

>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> >> To open a real can-of-worms, what would people on this list like to see in >> a low-end product offering? (Sub-$10k chassis). >This hypothetical discussion would be of great interest to me. :-) I'll take a crack at it: PC-ish Mini-tower not to exceed 19" high (so it could be rack mounted on its side) Lower-end Alpha or medium Intel processor (whatever's cheaper for NetApp) 256 MB RAM 4-8MB NVRAM Single 10/100 Ethernet Single SCSI Bus Up to 7 9GB (or larger?) disks A couple of PCI slots for other types of network interfaces, and/or SCSI Tape. Make it one box, disks and all. Don't worry about hot-swap or hot spare disks. If you're buying at this end of the market, down time probably costs you less than it does the big-boys. Instead, sell a cold-spare disk which sit on the shelf until they need it. If it saves mfg costs, solder the memory, nvram & ethernet to the motherboard. Ship a single config. With a max usable of +/- 50GB a box like this could be a departmental fileserver, or a NetCache box for small to medium organizations who don't need/want a big NetApp for the job. I don't know how close this comes to the $10K figure. It's probably closer to $20K maxed with disks. Still, that's my .$.02 worth Tony Paolucci System Administrator, Growth Management, Metro, Portland, Oregon

3 2

Re: budtool 4.6 / ndmp /restore
by dnb＠ccs.neu.edu 25 Feb '99

25 Feb '99

Douglas Ritschel <djr(a)research.bell-labs.com> writes: > We seem only to be able to restore files, that were backed up from our > Netapp 760 filer, to their original location on the Netapp. If I try to > restore a file to a different location on the Filer, than the location > that it was backed up from, I receive an error message saying that the > machine is not running ndmp. And the restore fails. > > Does anyone have experience with this? We had some interesting restore problems until we found out that you must create an "etc" directory at the top of each of your volumes (at least in 5.1.2* with Budtool 4.6). The filer will then create a "tmp" dir for you in that etc dir and use it as a staging area for your restore. Fascinating, no? Peace, dNb

3 2

budtool 4.6 / ndmp /restore
by Douglas Ritschel 25 Feb '99

25 Feb '99

We seem only to be able to restore files, that were backed up from our Netapp 760 filer, to their original location on the Netapp. If I try to restore a file to a different location on the Filer, than the location that it was backed up from, I receive an error message saying that the machine is not running ndmp. And the restore fails. Does anyone have experience with this?

2 1

RE: Net App and NetBackup
by Daisy Nguyen Davis 25 Feb '99

25 Feb '99

I DO NOT recommend Budtool! I have been using Budtool in the last 4 years. From the beginning, the support was wonderful even though the product was just so so. But since Budtool splits into 2 companies: budtool and Intelliguard, I have had many bad experiences with both product and support from Intelliguard. Many of their experience tech supports are gone. The new ones are nasty and inexperience. In my opinion, the product is not worth the headache. Daisy --------------------------------------- From: "Raymond Brennan" <ray_brennan(a)mentorg.com> Subject: RE: Net App and NetBackup MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <199902251256.NAA15704(a)uabs78c65.uab.ericsson.se> Sender: owner-toasters(a)mathworks.com Precedence: bulk X-Mozilla-Status2: 00000000 part text/plain 619 Press <return> to show content... I have been using Budtool from Intelliguard and can heartily recommend it-very stable, very easy to use and well supported. Raymond >-----Original Message----- >From: owner-toasters(a)mathworks.com >[mailto:owner-toasters@mathworks.com]On Behalf Of Michael Salmon >Sent: Thursday, February 25, 1999 12:57 PM >To: toasters(a)mathworks.com >Subject: Net App and NetBackup > > >I wondered if anyone was using NetBackup with their filers. We are >currently using Networker but are sufficiently dissatisfied that we >going to look at NetBackup and I am interested in any problem that >others have encountered. > >/Michael >

5 6

Problems w/ NetApp & BudTool 4.6
by Jason D. Kelleher 25 Feb '99

25 Feb '99

On the evening of Saturday February 20 we upgraded from BudTool 4.5 to 4.6. Since then, we've not been able to do local NDMP backups on our filer. Anyone out there experience similar problems? If so, would you please throw some suggestions my way. We have support calls open with both NetApp (being very helpful considering it's probably not an issue with their system) and Intelliguard (with what we pay them I'd assume they could at least hire warm bodies). Here's what we've come up with so far: 1) Intelliguard told us to add the line "ROBOT_SCSI_LUN 1" to the jbmgr_config for the filer. This allowed the jbmgr daemon to start. audreyii: /usr/budtool/bud [225] % cat jbmgr_config.audreyii.2 ROBOT_DEV_HOST nfssrv1 ROBOT_DEV_NAME spt0 ROBOT_SCSI_ID 2 ROBOT_SCSI_BUS 2 ROBOT_SCSI_LUN 1 DATA_DEV_NAME0 nrst0a DATA_DEV_HOST0 nfssrv1 PASSWORD xxxxxxxx USEBARCODE N VALIDATECMD "$BTHOME/bin/jbupdate audreyii:2 -a" audreyii: /usr/budtool/bud [226] % 2) Running the BudTool probe-scsi command shows the devices: audreyii: ~ [230] % probe-scsi -h nfssrv1 Copyright (c) 1990-1999 by Intelliguard Software Inc. probe-scsi BudTool 4.6 SCSI Bus 0 SCSI Bus 1 SCSI Bus 2 Target 2 Unit 0 Removable Tape EXABYTE EXB-8500 CC37 Unit 1 Removable Jukebox Device EXABYTE TZ Media Changer CC37 SCSI Bus 3 SCSI Bus 4 audreyii: ~ [231] % 3) After placing 2 labled BudToool tapes into the jukebox, running jbupdate returns instantly showing no tapes in the jukebox (doesn't even attempt to read tape labels). audreyii: ~ [236] % jbupdate audreyii:2 -a ------------------------------------------------------------------ ------ W A R N I N G ------- You have selected to force an update on all 5 tapes. This process requires several minutes per tape for unbarcoded tapes. Large jukeboxes with unbarcoded tapes can take several hours. The PID of this process is 8721. Use a HUP, INT, TERM or QUIT to terminate this process if you do not want to continue. ------------------------------------------------------------------ Update complete. audreyii: ~ [237] % jbmgr -H audreyii:2 ls -a 0: 1: 2: 3: 4: audreyii: ~ [238] % 4) We can perform remote NDMP backups to our BudTool master media server, but this isn't practical at ~2.2 GB/hr with 70+ GB on our filer. (It's an old, slow F330 which I'm supposed to be replacing instead of trouble-shooting...) 5) Gave Intelliguard a copy of our config file, the jbmgr diag log, and the probe-scsi output for analysis. The diag file does show some errors: 6) After not receiving much help from Intelliguard, we called NetApp. They sugggested we upgrade from 5.1.2P2 to 5.1.2R3P1 to remove the possibility that this was related to an NDMPD bug (6417). 7) Spoke to Intelliguard again Monday and informed them that we were going to upgrade the filer. We decided to see if the upgrade solved the problem. (They managed to fix a btcp issue after I waited 4 hours for a call back -- I'm still waiting for our sales rep to tell me exactly what kind of turn around to expect when paying extra for 24x7 support.) 8) Nothing changed after the upgrade Monday night. I informed NetApp; they opened another call and had us send them more info. 9) Told Intelliguard, gave them another copy of the diag file. 10) Configured BudTool to do lev 1 remote backups of the filer, this should hold us until the weekend. 11) Had to take a personal day Tuesday (for personal reasons). Hoped I get a couple voice/e-mails telling me that someone figured out what was wrong. (Finding out we were stupid and didn't have BudTool configured correctly would have been a relief.) 12) Wednesday we received some follow-up calls from NetApp, the call was escalated, and we're currently expecting a call. 13) We verified that tapes can be manually loaded into the jukebox drive and dump run on the console of the filer. Pretty confident that the jukebox didn't coincidentally die during the BudTool upgrade. 14) Will file missing persons reports for Intelliguard employees in another 24 hours. (Anyone have the number for the police in Dublin, CA?) So far, I'm confident it's a BudTool issue. (Many thanks/apologies to NetApp if it is.) I'd be very grateful if someone could give me a possible avenue of investigation. I'm at a dead-end and looking at over 30 hours of backups to lev 0 our filer this weekend... :( thanks, jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Partners, G.P. 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

2 1

Re: Shared Snapshot directory
by Daniel Quinlan 24 Feb '99

24 Feb '99

Dave Hitz <hitz(a)netapp.com> writes: > It remains to be seen whether or not we're crazy, but perhaps > I can convince you that we're not *completely* crazy. > > I understand your skepticism, because running the entire backup data > flow through Java would probably not result in acceptable performance. > > Our idea is to use Java to execute the Legato daemons, and to direct > the data movement, but to provide new primitives in WAFL that allow > Java to say things like: "stream the data from this inode to this > network connection." I'm not sure what all WAFL primitives Jim ended up > adding to boost performance, but hopefully you get the idea. We're not > talking about the normal Java I/O library here. > > So Java orchestrates the backup, but the data flow itself goes directly > from WAFL to the network, using the same basic code path as NFS, CIFS > or HTTP. Dave, This seems like marketing-deal-driven engineering. A backup system that requires every client to run a specialized daemon (which must be ported every time you want to use a new type of client) seems really broken to me. We're quite happy here using dump, restore, and (nowadays) NDMP. I'm worried that these additions will not only cause us problems on our filers, but will encourage Legato to kill off BudTool. Most of all, I don't really understand the effort being applied to Java/Legato when other simple, useful, and important protocols like SNTP, SNMP, and rsh are unsupported or neglected. - Dan

2 1

Too many open files...
by yrsuser 23 Feb '99

23 Feb '99

I have an F230 that is lightly used (relatively speaking) with NFS and CIFS enabled, and HTTPD - but no real web stuff on it yet. It's running 5.1R1 - and has been up for about 110 days. A few days ago, I started getting the following error, which shows up once a minute in the /etc/messages file: [httpd_log_main]: can't open /etc/log/httpd.log: too many open files I'm not seeing any other problems - my users are not having trouble getting to things in their home directories (primarly what we have on the F230). No disk errors, scrub errors, or other warnings in the logs. Is there a simple solution? I'd rather not have to reboot unless it becomes a real problem. I'm waiting for delivery of the current version of the OS, and will need to reboot to install that anyway. Cliff

1 0

cifs shares -delete ... {-force ?}
by Todd C. Merrill 23 Feb '99

23 Feb '99

There doesn't appear to be a "force" option to the `cifs shares -delete` command, that is available via an rsh: # rsh bat-toaster cifs shares -delete R12 The share R12 cannot be deleted; users are currently using it. However, if I do this on the console, it prompts me: bat> cifs shares -delete R12 Users have open files on R12. Continuing the operation will force the files closed. Do you want to continue this operation? [no]: yes and the share can be forcibly deleted. I need to be able to do this programmatically via an rsh command; the man pages for cifs_shares show no such option (forcegroup doesn't seem appropriate). Help! toaster info: R12 /vol/vol0/devel/R12 everyone / Full Control Files are open with both Exec-denyW and Read-denyN. NetApp Release 5.2.1: Thu Dec 31 12:56:45 PST 1998 Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

RE: Shared Snapshot directory
by Benn, Paul 23 Feb '99

23 Feb '99

I just wanted to clarify that if a UNIX backup server is used, it must use NDMP. If a multiprotocol Filer is backed up as an NFS volume, all of the NTFS permissions will be lost. If an NT backup package is used, the NTFS permissions and the UNIX permissions are retained. WAFL also keeps an archive bit for UNIX files so that an NT package can perform incremental backups. Keep an eye out for my new document titled "How to Integrate a Network Appliance Filer into the Windows NT Backup Model." It should be posted soon at: http://www.netapp.com/technology/apps.html Here's a snippet from one of the sections: 5.2 Using Windows NT to Automate Snapshot Backup The process described in Section 5.1 can be automated using features that are built into the Windows NT operating system. The Windows NT "at" scheduling service (briefly described in Section 2.4) can be used in combination with the "rsh" command to do this. Before it will work though, some minor preparation to the filer and to Windows NT will need to be performed. First, using a text editor, edit the "etc\hosts.equiv" file on the filer. Add a line as follows: #Use the host name or IP address. #If a host name is used, ensure #that it also appears in the /etc/hosts file. #Note the capital 'A' host_name Administrator Alternatively, this can be done using the FilerView GUI from a web browser. Next, from the Services option in the Windows NT Control Panel, configure the "Schedule" service to start automatically using the "Administrator" account. Configuring a Service to Start Using a Particular User Account Once the filer and Windows NT have been setup, schedule a batch process using the Windows NT "at" command. The following batch file, which uses NT Backup, is included as a reference: REM In this example, 'filer5' will be used as the name of the filer REM The qtree is called 'qtmixed,' which resides on a single REM volume filer. The default volume name is vol0. REM REM Delete the snapshot created by the previous run of this process rsh filer5 -l root snap delete vol0 openfiles REM REM Turn off oplocks, telling clients to release the file rsh filer5 -l root qtree oplocks qtmixed disable REM REM Create a snapshot directory called openfiles rsh filer5 -l root snap create vol0 openfiles REM REM Re-enable oplocks rsh filer5 -l root qtree oplocks qtmixed enable REM REM Map a drive letter to the filer's root share net use f: \\filer5\c$ REM REM Run the backup command - in this example NTBackup. REM Notice that '~snapshot' is used instead of '.snapshot' start /normal /b ntbackup backup f:\dir\~snapshot\ /hc:on /t normal REM End of file The above batch file (less the last few lines, launching a backup command) could also be used as a pre-job process with almost any Windows NT backup package. -----Original Message----- From: Daniel Quinlan [mailto:quinlan@transmeta.com] Sent: Monday, February 15, 1999 11:39 PM To: Patrick.Day.B(a)bayer.com Cc: toasters(a)mathworks.com Subject: Re: Shared Snapshot directory Patrick Day B <Patrick.Day.B(a)bayer.com> writes: > This is kinda long, so i appologize ahead of time... You're an NT shop, eh? I really strongly recommend using the Unix dump/restore facilities built into Data ONTAP -- it's *much* faster, it takes much of the complication out of the process, it preserves both NT and Unix attributes, and it works. Also use a Unix backup server (Solaris is probably best). For backup software, we have pretty good results with BudTool. Anyway, I think the way to do what you're trying to do is this: - create a share of / (actually, any directory, but the example here is /) - prior to backup, create a named snapshot ("mybackup.<num>") (this is what effectively happens when using dump) - backup from /.snapshot/mybackup.<num> or /.snapshot/mybackup.<num>/dir, - after backup, remove the named snapshot This way, you don't have to worry about the backups changing out from under you, and the CIFS locking of shares shouldn't affect you. However, I really want to warn you away from this... IMO, these are the basic mistakes made when backing up NetApps (in order of most bad to least bad): 1. backup up over a network filesystem (NFS or CIFS) instead of dump/restore 2. backup using NT backup host instead of Unix 3. backup across network instead of directly attached SCSI jukebox 4. backup from scheduled snapshots instead of manual ones (or ones created automatically by dump) 5. backup using rsh instead of NDMP 6. (for sites with more than a few hundred GB) backup using non-scalable home-grown scripts instead of "real" backup software 7. lesser mistakes: small blocksize, too large or small of a tree in one dump, backing up during the day, etc. I'm sure our backup guru would have a few items to add. :-) - Dan

5 4

Re: Nitech XRP1000 filer
by sirbruce＠ix.netcom.com 23 Feb '99

23 Feb '99

On 02/22/99 18:41:25 you wrote: > > Has anyone used the XRP 1000? It's Nitech's "answer" to the >Netapp (the even mention Network Appliance specifically as the market >leader in network-attached storage, and that they compete with Netapp). > >http://www.nitech.com/online/Company/Storage/XRP_1000/body_xrp_1000.html I've never used one, but... I went to the URL. I laughed. I cried. I want to surf it again and again. The company provides virtually no background info on itself. No listing of who's at the helm. It looks like it's operating out of somebody's garage... of course, Netapp started the same way, but at least they had some sense to put together something professional. The white paper is told in a somewhat folksy style; clearly it was written by someone just rambling and without much experience. It contains several grammatical and spelling errors. The presentation still refers to Network Appliance, Inc. as Network Appliance Corporation, and even uses the old abbreviation NAC. The docs also from time to time mention a few filer details that this product doesn't suffer from, like single telnet sessions. All this leads me to believe that this is some guy who was once familiar with them and who decided he could compete, without really understanding the underlying software technologies. The product may be good, but I have little faith in the company. Sure, even Netapp was once a nobody, but they were a lot more professional and had a lot more going for them. Bruce

1 0

Jump to page:

2026

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