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@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@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@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@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@netline.net.uk
-
Jason D. Kelleher