toasters

toasters@lists.teaparty.net

13520 discussions

autosupport debug
by Graham C. Knight 21 Sep '99

21 Sep '99

A few weeks ago somebody on the list told me about an option that could be set to help debug a lack of autosupport mail after reboot. autosupport works fine, except occasionally there will be no autosupport mail when a system reboots. (5.2.3). I lost the mail. Hopefully whoever it was can send it to me again. Sorry to bother the whole list with this. Thanks, Graham

3 2

RE: autosupport mail (Was RE: tech support waits)
by Datta, Diptish 21 Sep '99

21 Sep '99

Excellent suggestions. Both of them. I will fllow up on this with engineering. -diptish > -----Original Message----- > From: Garrett Burke [mailto:Garrett.Burke@msc.ie] > Sent: Tuesday, September 21, 1999 2:12 AM > To: 'Datta, Diptish' > Cc: toasters(a)mathworks.com > Subject: autosupport mail (Was RE: tech support waits) > Importance: High > > > Hi Diptish, > > With regards to NetApp starting to use the autosupport mail > for automated > suggestion of bug fixes might I suggest two things: > > a) That the contents of the autosupport mail be made configurable For > example I like autosupport mail, but I don't like the NT Share ACLs, > usernames nor connected hosts being included as this leaks > internal security > information (running 5.2.1). The mails are already in > sections so your > automated system could use these to see what info is avalable > in the mail. > > I understand that the more information that I provide to support the > quicker the fix, but it's a shame that it might be an all or nothing > decision as regards auto support. > > b) Provide your customers with the same scripts that you use > to process > autosupport so it can be done on site or at least provide a > 'what to look > for in autosupport mails' guide right down to the nitty > gritty like 'If nbt > disconnects are more than .1% of your total CIFS operations > then you should > investigate for possible network problems' (Given the info & > the time I'd > write my own scripts and use qpage to page me when things got > nasty. I'd > happily share such scripts) > > Providing the customers with the scripts would allow those > sites that don't > want to run autosupport mails the ability to place a support > call and be > able to give more info than at present e.g. 'I'm running 5.3.2 and > autosupport processing script v1.3 is giving a problem #44 - > disk showing > recurring errors' > > It's in our (i.e. filer users) interest to provide as much > info as possible > to help CS solve the > problem and NetApp can help us to provide that info. Support > is a two way > thing. > > Thanks for taking the time to listen to users comments > > Regards, > GB. > > ---------- > > From: Datta, Diptish[SMTP:diptish.datta@netapp.com] > > Sent: 21 September 1999 07:11 > > To: 'sirbruce(a)ix.netcom.com' > > Cc: toasters(a)mathworks.com > > Subject: RE: tech support waits > > > > >

1 0

OS2/Warp CIFS Clients?
by Mohler, Anissa 21 Sep '99

21 Sep '99

Hello all - I really doubt this is out there... but I have to give it a shot. My filer FINALLY went into production mode last night and this morning I found out that the ONE OS2/Warp Client in the company does not see the filer, at all. All other CIFS clients see the filer and are operating flawlessly. The OS2/Warp client was configured to work with NT 4.0 Servers and had no problems. You would think that the OS2 box wouldn't have any problems since it works with NT now. I'm putting some static mappings in WINS and verifying the Filer is in DNS just to be on the safe side, but I am thinking the OS2/Warp box doesn't see the filer because it is not supported by ONTAP. (We are running ONTAP version 5.3.2R1.) Has anyone tried to get an OS2/Warp client to see a filer? Has anyone been successful? This is one of those things that would be nice to have work... but if it doesn't it won't hurt. Anissa Mohler amohler(a)mail.bokf.com BOk Technical Services desk - 918.295.0431 Network Services Group pgr - 918.672.1214

1 0

RE: tech support waits
by Datta, Diptish 21 Sep '99

21 Sep '99

Some comments in line ... Some of your comments I don't agree with and some points are very valid. But in summary I think what you are saying is you want to see the results. These changes are things we are working on. We'll have to wait to see the results. > -----Original Message----- > From: sirbruce(a)ix.netcom.com [mailto:sirbruce@ix.netcom.com] > Sent: Monday, September 20, 1999 12:45 PM > To: diptish.datta(a)netapp.com; armijo(a)cs.unm.edu > Cc: toasters(a)mathworks.com > Subject: RE: tech support waits > Importance: High > > > On 09/19/99 21:35:17 you wrote: > > > >Steve, > >I can see how the "proactive" response to a disk failure > autosupport would leave > >you rather unimpressed when the call back is after you have > already acted on it > >yourself! Fact of the matter is, that is indeed the way it > is today. Autosupport > >is filtered by a script and the ones needing attention (eg > DISK_FAIL) are > >forwarded to CSRs for attention. A call is logged and the > customer is contacted. > >Now, the info in the autosupport is not very CS-friendly > because the info that > >we need to locate the customer is not mandatory. So, often > it slows down the > >process of logging the call, finding the contact information, etc. > > In other words, Network Appliance implemented autosupport > without committing > to the staffing necessary to support all of the events > generated. The solution > then is either to ditch autosupport, or increase staffing. > Productivity > enhancements to the process (i.e. automation) are fine, but > are not enough by > themselves in the long term unless the fundamental issue is resolved. ############# I completely disagree. When autosupport was designed we thought of a lot of benefits we could get from it. Post processing the data to collect install base profile and such is one example. That is still valid. We also designed alerts that CS could trap and respond to proactively. We have a group of Customer Support Reps who are dedicated to processing autosupport alerts. We never claimed this to be a *substitute* for you being responsible for your filers. For example, when a drive fails, we designed the process to alert CS, log a call and RMA a drive. But if you receive the autosupport notification also (which is what we expect) then you will make sure that a spare was available and reconstruction completed. As a company grows, its success challenges existing processes. That is what we are faced with today. The solution is not increased staffing - the solution is automation. That is the only way we will be able to scale. And that is what we are shooting for. > > >We are looking at correcting these bottleencks by proposing > changes to > >Engineering that would make contact and customer information > mandatory in > >autosupport. > > So your solution is to shift more work off to the customer? Shift work to the customer? Entering contact information in a setup screen is that much extra work? Ok .... > Not a good > strategy. You should keep it optional so that customers can still get > *some* benefit out of autosupport if they chose, even if it > means Netapp > won't be able to respond their quickest. A simple note in > the documentation > making it clear that the more information the better would be > sufficient. Agreed. We can't make it mandatory any way because of secure sites and such. > > Furthermore, the customer information is not going to be kept > up to date > by many sites. IT professionals have too much to do as it > is; one reason > why *you* are paid for *support* is so that *you* do some of > that work. > It is not unreasonable for support to try to keep their > records updated. Paid or not, I'm not sure how we would keep our database info updated without input from the customers. The NOW site is one channel that allows you to tell us the info - I'm thinking autosupport may be another way for us to keep the info current. > > >We also have a team engaged right now to scope out automation > >around autosupport. If, for example, locating a customer > record in our database > >was simple and guaranteed (programatically) then a script > could field the > >DISK_FAIL autosupport, log a call, check the customer's > service level, issue the > >RMA and email you back the call log number and the shipment > info. (Know anyone > >that could help us with this project? :-). > > This sort of automation should have been done years ago. > Doing it now depends > a lot on your choice of customer database and may require a > new one if your old > one was not properly planned. As to who can help you, you're > in the heart of > Silicon Valley... look out the window and wave some stock > options around. Or > consider offer existing personnel additional incentives to do > the task. (Why > do we have to tell you this?) No - you really did not have to say any of that! :-) I'll pass on the idea of waving stock certificates out the window to the recruiters that are working full time trying to find people the hard way. > > >We are also thinking about automating the analysis of a > crash - I think we > >should be able to suggest patches just based on info in > autosupport ... at least > >some percent of the cases. Not sure how successful this will > be. But it would be > >really cool even if we were able to auto-analyze and propose > upgrades for 25% of > >the cases! > > This is a good idea. Thanks!!! > The wording will have to be careful to > distinguish between > "This looks like a known bug and we think this upgrade may > fix the problem" and > "We don't know specifically about this problem, but it may be > fixed by going to > the latest recommended version" and also catching those cases > where the latter > advice might actually be unwise. This can help in the > response time but in many > cases you will ultimately need some actual human intervention > to follow-up. Good points. > > >This should be possible. Autosupport has a lot of untapped > benefits that we can > >take advantage of. It is not straightforward - but you > should see some changes > >in the future - for the better. > > Look, I know this message sounded harsh. No need to respond. > But I recognize > corporate PR song and dance when I see it and it pushes one > of my hot buttons > to see it on this list. Looking at resolving the problem? > It's been around > for a long time. Considering more automation? I bet you > would have said the > same thing 5 years ago. Explanations are fine, but excuses > are just excuses. > Customers want to see results. Harsh? Naaah! Bruce, I appreciate your input. Honestly, 5 years ago (if we had autosupport 5 years ago - which we didn't) we though that the volume would be manageable. We were wrong. We did not have a problem dealing with the volume then. Now we do. Automation is now necessary. Results are what matter. Proof is in the pudding and all that. Agreed. I am not in PR - I am in CS. So, this is important to us. I can not tell you what we will end up with - all I am saying is that the areas I mentioned are areas that we are working on. > > Bruce > > Diptish Datta Director, Product Support Network Appliance

1 0

RE: tech support waits
by sirbruce＠ix.netcom.com 20 Sep '99

20 Sep '99

On 09/19/99 21:35:17 you wrote: > >Steve, >I can see how the "proactive" response to a disk failure autosupport would leave >you rather unimpressed when the call back is after you have already acted on it >yourself! Fact of the matter is, that is indeed the way it is today. Autosupport >is filtered by a script and the ones needing attention (eg DISK_FAIL) are >forwarded to CSRs for attention. A call is logged and the customer is contacted. >Now, the info in the autosupport is not very CS-friendly because the info that >we need to locate the customer is not mandatory. So, often it slows down the >process of logging the call, finding the contact information, etc. In other words, Network Appliance implemented autosupport without committing to the staffing necessary to support all of the events generated. The solution then is either to ditch autosupport, or increase staffing. Productivity enhancements to the process (i.e. automation) are fine, but are not enough by themselves in the long term unless the fundamental issue is resolved. >We are looking at correcting these bottleencks by proposing changes to >Engineering that would make contact and customer information mandatory in >autosupport. So your solution is to shift more work off to the customer? Not a good strategy. You should keep it optional so that customers can still get *some* benefit out of autosupport if they chose, even if it means Netapp won't be able to respond their quickest. A simple note in the documentation making it clear that the more information the better would be sufficient. Furthermore, the customer information is not going to be kept up to date by many sites. IT professionals have too much to do as it is; one reason why *you* are paid for *support* is so that *you* do some of that work. It is not unreasonable for support to try to keep their records updated. >We also have a team engaged right now to scope out automation >around autosupport. If, for example, locating a customer record in our database >was simple and guaranteed (programatically) then a script could field the >DISK_FAIL autosupport, log a call, check the customer's service level, issue the >RMA and email you back the call log number and the shipment info. (Know anyone >that could help us with this project? :-). This sort of automation should have been done years ago. Doing it now depends a lot on your choice of customer database and may require a new one if your old one was not properly planned. As to who can help you, you're in the heart of Silicon Valley... look out the window and wave some stock options around. Or consider offer existing personnel additional incentives to do the task. (Why do we have to tell you this?) >We are also thinking about automating the analysis of a crash - I think we >should be able to suggest patches just based on info in autosupport ... at least >some percent of the cases. Not sure how successful this will be. But it would be >really cool even if we were able to auto-analyze and propose upgrades for 25% of >the cases! This is a good idea. The wording will have to be careful to distinguish between "This looks like a known bug and we think this upgrade may fix the problem" and "We don't know specifically about this problem, but it may be fixed by going to the latest recommended version" and also catching those cases where the latter advice might actually be unwise. This can help in the response time but in many cases you will ultimately need some actual human intervention to follow-up. >This should be possible. Autosupport has a lot of untapped benefits that we can >take advantage of. It is not straightforward - but you should see some changes >in the future - for the better. Look, I know this message sounded harsh. No need to respond. But I recognize corporate PR song and dance when I see it and it pushes one of my hot buttons to see it on this list. Looking at resolving the problem? It's been around for a long time. Considering more automation? I bet you would have said the same thing 5 years ago. Explanations are fine, but excuses are just excuses. Customers want to see results. Bruce

2 1

RE: tech support waits
by Datta, Diptish 20 Sep '99

20 Sep '99

Steve, I can see how the "proactive" response to a disk failure autosupport would leave you rather unimpressed when the call back is after you have already acted on it yourself! Fact of the matter is, that is indeed the way it is today. Autosupport is filtered by a script and the ones needing attention (eg DISK_FAIL) are forwarded to CSRs for attention. A call is logged and the customer is contacted. Now, the info in the autosupport is not very CS-friendly because the info that we need to locate the customer is not mandatory. So, often it slows down the process of logging the call, finding the contact information, etc. We are looking at correcting these bottleencks by proposing changes to Engineering that would make contact and customer information mandatory in autosupport. We also have a team engaged right now to scope out automation around autosupport. If, for example, locating a customer record in our database was simple and guaranteed (programatically) then a script could field the DISK_FAIL autosupport, log a call, check the customer's service level, issue the RMA and email you back the call log number and the shipment info. (Know anyone that could help us with this project? :-). We are also thinking about automating the analysis of a crash - I think we should be able to suggest patches just based on info in autosupport ... at least some percent of the cases. Not sure how successful this will be. But it would be really cool even if we were able to auto-analyze and propose upgrades for 25% of the cases! This should be possible. Autosupport has a lot of untapped benefits that we can take advantage of. It is not straightforward - but you should see some changes in the future - for the better. Diptish Datta Director, Product Support Network Appliance > -----Original Message----- > From: armijo(a)cs.unm.edu [mailto:armijo@cs.unm.edu] > Sent: Thursday, September 16, 1999 7:23 PM > To: jay(a)cimedia.com > Cc: toasters(a)mathworks.com > Subject: Re: tech support waits > Importance: High > > > > > > I opened another case on the same day that was resolved that > > week. Interestingly, on this second case, NetApp also > opened a case on > > my behalf over the same issue in response to an autosupport email my > > NetApp generated when it crashed. > > > > NetApp is extremely inconsistent about this. Our filers > have probably > > crashed a half dozen to a dozen times in the couple of years we've > > owned them and this is the only time I've seen the autosupport email > > cause a case to be opened. > > I have seen the same thing. I had a filer throw a disk one > night, I called > in, got a disk sent to me, got it 6 hours later( our support > contract says > 4 ), and dropped it in place. then the next day i had > someone from netapp > call me with an open case and explain they wanted to ship me > another disk, > and had a new case opened for me. > > other times i have had a filer reboot on random crashes, and > never heard > a thing. > > on th eother hand, it is nice to be able to get a warm body > on the phone 24 > hours a day, now if only there was a way to escalate faster... > > -steve > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] >

1 0

RE: Best way to copy data to new filer ??
by Vine, Ben 17 Sep '99

17 Sep '99

Depending on the size of your data, and the downtime you are willing to stand, you might want to use SnapMirror as the migration tool. It has the disadvantage of not being able to merge 2 volumes, but it is definitely the best way to migrate with minimum downtime. Ben Vine SE & Support Manager, ISRAEL Network Appliance Tel: +972-54-759007 Email: bvine(a)netapp.com What doesn't kill you, makes you stronger... -----Original Message----- From: David H. Brierley [mailto:dhb@ssd.ray.com] Sent: Tuesday, September 14, 1999 6:19 PM To: toasters(a)mathworks.com Subject: Best way to copy data to new filer ?? I am getting ready to convert from an F220 and an F230 to an F740. Does anyone have any recomendations on how to copy all of the data from the two old filers to the new one? I know I can use dump and restore but I was wondering if maybe "vol copy" would be more efficient. Can I use "vol copy" to copy the entire contents of two existing filers to a single new one? If so, can it merge the contents into a single volume or should I create multiple volumes? -- David H. Brierley Raytheon Systems Company - Portsmouth RI Facility Work: dhb(a)ssd.ray.com Home: dave(a)galaxia.com

1 0

Re: tech support waits
by Skinner, Alistair 17 Sep '99

17 Sep '99

Hi Todd, My name is Alistair Skinner. I run the global support center at Network Appliance, and was passed your comments concerning the our email responsiveness and holdtimes. Thanks for taking the time to give us some feedback. I'll make sure we follow up with you on your specific support cases, but wanted to let you know what we're doing generally on web access and phone holdtimes. Our preferred method of online access is through the web. Using the email option from within a case view gives you a pre-formatted subject line to make sure the email is attached to the case in our system. The comments field can also be used. Unfortunately currently there can be up to a day delay between you submitting something and it getting into our system as these updates are batched. We expect to have an enhanced version implemented in the next two months which will include immediate updates directly to the case. Regarding phone responsiveness, due to our continued growth, we still experience some long holdtimes at certain times of the day. We have 10 new staff who will complete their training over the next few weeks, and we are in the middle of reallocating existing staff within the various specialty groups to better match resources to demand. Additionally this week we have changed our process behind the "the filer is not serving data" option - instead of queuing blindly for the next available support engineer, these calls are now routed to our customer support group who will connect you directly with a support engineer if your system is down. I also wanted to let you know as an additional resource, if you have concerns about how a case is being handled, you can call 1-888-4NETAPP, select the "new case" option, and ask to speak to the Duty Manager. Thanks again for your feedback, Alistair Alistair Skinner Network Appliance alistair.skinner(a)netapp.com 408-822-6339

4 3

Is the Postmark source code stilll available?
by sthaug＠nethelp.no 17 Sep '99

17 Sep '99

The Postmark source code, referenced from http://www.netapp.com/tech_library/postmark.html http://www.netapp.com/tech_library/3022.html appears to be no longer available from the Netapp web site. The source code is supposed to be at http://www.netapp.com/ftp/postmark-1.11.c.gz but this URL gives a 404 Page not found error. Does anybody know if the Postmark source code is still available? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 2

Re: Best way to copy data to new filer ??
by Luke Mewburn 15 Sep '99

15 Sep '99

Nick Hilliard writes: > The other problem with it is that if you've got lots of files, it tends to > consume vast amounts of memory. Last time I used it for syncing a large > volume (over 3M files), it required about 600 megs of memory (for which swap > works fine). Yes, that's true. It can also get a bit CPU bound. That's why it can pay to break up the rsync into multiple processes (one for each subdir) and split them across multiple processors.

1 0

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