toasters

toasters@lists.teaparty.net

13515 discussions

RE: Will F760 work with IBM ADSM backup system?
by Mohler, Jeff 01 Mar '99

01 Mar '99

From what I understand (sorry if this is already answered) IBM had NA hardware in the Lab, and we should expect a Java engine for it soon. Williams is crying for it. > -----Original Message----- > From: Mike Ball [SMTP:mball@rtp.opensystems.com] > Sent: Monday, March 01, 1999 10:30 AM > To: 'toasters(a)mathworks.com' > Subject: Will F760 work with IBM ADSM backup system? > > Does anyone know if the F760 will work with the IBM ADSM backup system? > The ADSM system is used to backup over 200 NT servers over the network, > and we would like to use it > to backup the F760 filer running CIFS. Has anyone had any experience with > the IBM ADSM > backup system and any Netapp filer?

1 0

Re: nightly.1 busy: snapshot rollovers not happening
by Mark Muhlestein 01 Mar '99

01 Mar '99

The best way to do this is to create a special snapshot specifically for the backup, then delete it when the backup completes. This avoids the problem of the snapshot being changed out from under you. And this can all be automated with scripts. See Paul Benn's message for a pointer to a description of how to do this. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Patrick.Day.B(a)bayer.com <Patrick.Day.B(a)bayer.com> To: - (052)toasters(a)mathworks.com <toasters(a)mathworks.com>; - (052)tmerrill(a)mathworks.com <tmerrill(a)mathworks.com> Date: Monday, March 01, 1999 10:48 AM Subject: Re: nightly.1 busy: snapshot rollovers not happening >I ran across this same problem when i shared the Nightly.0 for backup >purposes. When the nightly.0 rolls over to the Nightly.1, the CIFS share keeps >track and actually keeps the share mapped to nightly.1. (same thing next night >when it rolls over to nightly.3). I posted the problem a few weeks ago and the >only "solution" anyone could come up with was running an rsh command to stop >and recreate the share every time the backup runs. I opted to forget the >snapshot directory backup and go with a live backup of the C$\ share.

1 0

Re: nightly.1 busy: snapshot rollovers not happening
by Mark Muhlestein 01 Mar '99

01 Mar '99

>I suspect it's a CIFS locking issue. So, is there a way to *force* the >automatic nightly snapshot to rollover? If not, I guess I'll just hand-job >this to do "manual automatic" snapshots at midnight and `snap rename` the >busy ones. <sigh> What's the use of having the automated capability if >it doesn't work when files are locked, he sarcastically muttered >under his breath... ;) No, it's probably because you have a CIFS share defined on the snapshot. >It's ain't being dumped, and never has been, so it's a CIFS share issue. Exactly. Doing 'cifs shares' should show you the share defined on the snapshot. (For NFS folks, a CIFS 'share' corresponds to an NFS 'export'.) You can do a 'cifs shares -delete sharename' to remove the share. >(`cifs sessions *` works. Wo-hoo! But, which one is holding that >particular snapshot busy?) Snapshots can't be held from expiring by open files. It's the fact that a share is defined on the snapshot that is the problem here. (Another good question for the FAQ I guess.) Mark Muhlestein -- mmm(a)netapp.com

2 1

Re: nightly.1 busy: snapshot rollovers not happening
by Patrick.Day.B＠bayer.com 01 Mar '99

01 Mar '99

I ran across this same problem when i shared the Nightly.0 for backup purposes. When the nightly.0 rolls over to the Nightly.1, the CIFS share keeps track and actually keeps the share mapped to nightly.1. (same thing next night when it rolls over to nightly.3). I posted the problem a few weeks ago and the only "solution" anyone could come up with was running an rsh command to stop and recreate the share every time the backup runs. I opted to forget the snapshot directory backup and go with a live backup of the C$\ share. --Patrick Day owner-toasters(a)mathworks.com on 03/01/99 01:34:39 PM Please respond to "DDA.RFC-822=tmerrill(a)mathworks.com/P=Internet/A= /C=us" @ X400 To: "DDA.RFC-822=toasters(a)mathworks.com/P=Internet/A= /C=us"@X400 cc: "DDA.RFC-822=tmerrill(a)mathworks.com/P=Internet/A= /C=us"@X400 Subject: nightly.1 busy: snapshot rollovers not happening Folks, What does this "busy" mean? bat> snap list Volume vol0 working.................................................... %/used %/total date name ---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Mar 01 11:01 hourly.0 0% ( 0%) 0% ( 0%) Mar 01 10:01 hourly.1 2% ( 2%) 1% ( 1%) Mar 01 09:01 hourly.2 14% (13%) 11% ( 9%) Feb 27 00:01 nightly.0 22% (15%) 19% (12%) Feb 26 00:00 nightly.1 (busy) The nightly snapshot apparently didn't roll over, and hence a lot of testing suites that we run that depend on an image at mignight are giving us out of date results. The word "busy" is not mentioned anywhere in the ontap html docs (NetApp Release 5.2.1: Thu Dec 31 12:56:45 PST 1998). I've searched the archives for this list, and hit upon a similar thread just a few weeks ago (RE: Shared Snapshot directory), but the discussion went off on backups, not why the rollover wasn't happening. I suspect it's a CIFS locking issue. So, is there a way to *force* the automatic nightly snapshot to rollover? If not, I guess I'll just hand-job this to do "manual automatic" snapshots at midnight and `snap rename` the busy ones. <sigh> What's the use of having the automated capability if it doesn't work when files are locked, he sarcastically muttered under his breath... ;) And, if nightly.1 is busy, how come nightly.0 wasn't just replaced with one dated "Mar 01 00:01" instead? I realize the implications to possible Windows clients: programs dying, BSODs, etc., but that's okay in this environment. And, since these areas are read-only, there should be no data loss, yes? And, how TF do I get rid of this without rebooting the filer? bat> snap delete nightly.1 Snapshot in use by dump or a CIFS share. It's ain't being dumped, and never has been, so it's a CIFS share issue. (`cifs sessions *` works. Wo-hoo! But, which one is holding that particular snapshot busy?) (1-month newbie to NetApp filers, still learning the intricacies... Thanks for listening.) 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: Will F760 work with IBM ADSM backup system?
by Benn, Paul 01 Mar '99

01 Mar '99

Here's a link: http://www.netapp.com/technology/level3/3052.html Please keep in mind, though, that a more current version of this white paper will be posted within the next few days. Once it's posted (official), there will be a link to it on the "technology/applications" page: http://www.netapp.com/technology/apps.html Regards, Paul -----Original Message----- From: Mark Muhlestein [mailto:mmm@netapp.com] Sent: Monday, March 01, 1999 9:12 AM To: toasters(a)mathworks.com Subject: Re: Will F760 work with IBM ADSM backup system? 8><----snip----snip----snip---- The filer's NT backup also includes the ability to fully back up UNIX metadata. Paul Benn at Netapp has a white paper that describes how to use NT backup utilities with the filer. Paul, can you post a pointer to the toasters list? I can't seem to locate it. 8><----snip----snip----snip----

1 0

Re: Will F760 work with IBM ADSM backup system?
by Mark Muhlestein 01 Mar '99

01 Mar '99

If ADSM can back up an NT member server via CIFS it should work. According to the ADSM FAQ I found: "4. Can ADSM backup remote machines? "ADSM does not have a specific remote backup function. Any remote NTFS file system access needs to appear to the ADSM client as a local NTFS. "Remote drives can be backed up." So it would probably work by mapping a drive from the filer. However, we haven't tested ADSM to my knowledge. The filer's NT backup also includes the ability to fully back up UNIX metadata. Paul Benn at Netapp has a white paper that describes how to use NT backup utilities with the filer. Paul, can you post a pointer to the toasters list? I can't seem to locate it. David's point about sparse files is correct: sparse files will be expanded when restored. For CIFS-created files that is not a problem since the clients can't create them (until Win2k). Mark -----Original Message----- From: David Drum <david(a)more.net> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Monday, March 01, 1999 8:44 AM Subject: Re: Will F760 work with IBM ADSM backup system? >Quoth Mike Ball: > >> Does anyone know if the F760 will work with the IBM ADSM backup system? > >There is no ADSM client for NetApps, so it would have to backup through >an NFS mount. > >> Has anyone had any experience with the IBM ADSM backup system >> and any Netapp filer? > >Please be aware that ADSM does not back up UNIX sparse files properly. >(Last time I checked anyway.)

1 0

nightly.1 busy: snapshot rollovers not happening
by Todd C. Merrill 01 Mar '99

01 Mar '99

Folks, What does this "busy" mean? bat> snap list Volume vol0 working.................................................... %/used %/total date name ---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Mar 01 11:01 hourly.0 0% ( 0%) 0% ( 0%) Mar 01 10:01 hourly.1 2% ( 2%) 1% ( 1%) Mar 01 09:01 hourly.2 14% (13%) 11% ( 9%) Feb 27 00:01 nightly.0 22% (15%) 19% (12%) Feb 26 00:00 nightly.1 (busy) The nightly snapshot apparently didn't roll over, and hence a lot of testing suites that we run that depend on an image at mignight are giving us out of date results. The word "busy" is not mentioned anywhere in the ontap html docs (NetApp Release 5.2.1: Thu Dec 31 12:56:45 PST 1998). I've searched the archives for this list, and hit upon a similar thread just a few weeks ago (RE: Shared Snapshot directory), but the discussion went off on backups, not why the rollover wasn't happening. I suspect it's a CIFS locking issue. So, is there a way to *force* the automatic nightly snapshot to rollover? If not, I guess I'll just hand-job this to do "manual automatic" snapshots at midnight and `snap rename` the busy ones. <sigh> What's the use of having the automated capability if it doesn't work when files are locked, he sarcastically muttered under his breath... ;) And, if nightly.1 is busy, how come nightly.0 wasn't just replaced with one dated "Mar 01 00:01" instead? I realize the implications to possible Windows clients: programs dying, BSODs, etc., but that's okay in this environment. And, since these areas are read-only, there should be no data loss, yes? And, how TF do I get rid of this without rebooting the filer? bat> snap delete nightly.1 Snapshot in use by dump or a CIFS share. It's ain't being dumped, and never has been, so it's a CIFS share issue. (`cifs sessions *` works. Wo-hoo! But, which one is holding that particular snapshot busy?) (1-month newbie to NetApp filers, still learning the intricacies... Thanks for listening.) 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

Will F760 work with IBM ADSM backup system?
by Mike Ball 01 Mar '99

01 Mar '99

Does anyone know if the F760 will work with the IBM ADSM backup system? The ADSM system is used to backup over 200 NT servers over the network, and we would like to use it to backup the F760 filer running CIFS. Has anyone had any experience with the IBM ADSM backup system and any Netapp filer?

2 1

Re: Problems w/ NetApp & BudTool 4.6
by Jay Sekora 01 Mar '99

01 Mar '99

Garret Flynn <flynng(a)iol.ie> wrote: > I think your looking for BudTool46-2 > > $ more BudTool46-2.README [snip] > > * [PR 7273] btmerge fails for media server names that include "." [snip] > The bad news is that I checked today and this patch is no longer in > ftp://ftp.iguard.com/pub/dist/patch/BudTool/BudTool46 > Anymore. Intelliguard gave us a copy of this patch, and it didn't solve the problem for us. The merge still died. We changed to unqualified names, and then it started working. So the patch did *not* perform as advertised. I'm really happy with the way our backups are running now that we finally have BudTool working properly, but I am *not* impressed with Intelliguard's technical support or QA. (BTW, a hideous workaround for backing up NetApps across multiple DNS domains would be to give the toasters all CNAME entries in the domain the BudTool host was in.) -j. Jay Sekora <jay(a)ccs.neu.edu> Unix Systems Administrator Northeastern University College of Computer Science

1 0

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

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