In message 35119FA5.91C737AD@lucent.com, Dave Heiland writes:
This annoys me since I reported last year when I first set up my Netapp tha t NIS wasn't working right. Performance was awful, and it was rebinding to a different NIS slave every couple of seconds. I never heard much back, and because I immediately switched to using local netgroups I didn't have the problem again. At least there will finally be a fix.
Dave
I wouldn't get your hopes up. I was sent that message over 5 months ago...
jason
When we first turned on NIS, everything went to hell. The filerstarted denying mounts to all the clients. Unfortunately, it didn't do this right away, took several hours. Seems the filer wasn't getting netgroup info. Anyway, here's what NetApp told me:
Hi Jason,
I had one of our escalation engineers look over this call with me.
We believe that what you saw when upgrading to 4.1d is the result of an inefficient method we use to "lookup" the YP information. Instead of doing 3 or 4 lookups to get the netgroup info when the mount is checked we would do one for *every* line in the netgroup file.
This behavior has been logged as bug#4088 in our database and engineering is working to modify the NIS client to correct this problem.
For now the recommendation would be to continue using the local file method which hasn't caused you any problems. When a fix is available for #4088 then you could upgrade and begin using the NIS client for netgroup which should be much faster. One of the benefits of NIS client is that these lookups should be faster but with our first release of this NIS client they simply are not.
I have flagged this call record as bug#4088 with all the info you sent to me. The escalation engineer I spoke with is actually the one that will fix the NIS code and by flagging your call record as this bug he can review it during the time he makes the patch.
This would first be available as a patch release (a release with a capital D in it such as you were running prior to upgrading to 4.1d). The best way to find out when it is available would be to call back and reference the bug#4088 and ask if Eirik has a patch for the NIS client yet. I would think that you might want to wait 30 days or so -- there is no schedule for a fix date for this right now.
Regards, Gil
I never bothered to check back. NOW lists bug #4088 as unfixed.Here's our nsswitch.conf which "solved" our problems:
# # nfssrv1:/etc/nsswitch.conf #
passwd: files nis group: files nis
hosts: files nis dns netgroup: files nis
Good Luck.
Jason D. Kelleher kelleher@susq.com Susquehanna Investment Group 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122
My local NetApp support rep says bug #4088 was fixed in ONTAP 4.3R4D2. I'm trying to get further confirmation and information.
The NOW website needs a lot of work!
John
Jason D. Kelleher wrote:
In message 35119FA5.91C737AD@lucent.com, Dave Heiland writes:
This annoys me since I reported last year when I first set up my Netapp tha t NIS wasn't working right. Performance was awful, and it was rebinding to a different NIS slave every couple of seconds. I never heard much back, and because I immediately switched to using local netgroups I didn't have the problem again. At least there will finally be a fix.
Dave
I wouldn't get your hopes up. I was sent that message over 5 months ago... jasonWhen we first turned on NIS, everything went to hell. The filerstarted denying mounts to all the clients. Unfortunately, it didn't do this right away, took several hours. Seems the filer wasn't getting netgroup info. Anyway, here's what NetApp told me:
Hi Jason,
I had one of our escalation engineers look over this call with me.
We believe that what you saw when upgrading to 4.1d is the result of an inefficient method we use to "lookup" the YP information. Instead of doing 3 or 4 lookups to get the netgroup info when the mount is checked we would do one for *every* line in the netgroup file.
This behavior has been logged as bug#4088 in our database and engineering is working to modify the NIS client to correct this problem.
For now the recommendation would be to continue using the local file method which hasn't caused you any problems. When a fix is available for #4088 then you could upgrade and begin using the NIS client for netgroup which should be much faster. One of the benefits of NIS client is that these lookups should be faster but with our first release of this NIS client they simply are not.
I have flagged this call record as bug#4088 with all the info you sent to me. The escalation engineer I spoke with is actually the one that will fix the NIS code and by flagging your call record as this bug he can review it during the time he makes the patch.
This would first be available as a patch release (a release with a capital D in it such as you were running prior to upgrading to 4.1d). The best way to find out when it is available would be to call back and reference the bug#4088 and ask if Eirik has a patch for the NIS client yet. I would think that you might want to wait 30 days or so -- there is no schedule for a fix date for this right now.
Regards, Gil
I never bothered to check back. NOW lists bug #4088 as unfixed.Here's our nsswitch.conf which "solved" our problems:
# # nfssrv1:/etc/nsswitch.conf #
passwd: files nis group: files nis
hosts: files nis dns netgroup: files nis
Good Luck.
Jason D. Kelleher kelleher@susq.com Susquehanna Investment Group 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122
My local NetApp support rep says bug #4088 was fixed in ONTAP 4.3R4D2. I'm trying to get further confirmation and information.
The NOW website needs a lot of work!
Okay. Our internal bug DB says that bug 4088 is open (i.e. not fixed in a regular release), but that it is in patch releases 4.3R4D2, and also that it'll be fixed in a regular release coming out this summer.
Dave
In message 199803201556.HAA06962@jerseycity.netapp.com, Dave Hitz writes:
My local NetApp support rep says bug #4088 was fixed in ONTAP 4.3R4D2. I'm trying to get further confirmation and information.
The NOW website needs a lot of work!
Okay. Our internal bug DB says that bug 4088 is open (i.e. not fixed in a regular release), but that it is in patch releases 4.3R4D2, and also that it'll be fixed in a regular release coming out this summer.
Dave
In what version of ONTAP? I currently have an Intel based F330. No 5.0 for me... :( Or will 5.x eventually be ported to the Intel filers?
jason
Okay. Our internal bug DB says that bug 4088 is open (i.e. not fixed in a regular release), but that it is in patch releases 4.3R4D2, and also that it'll be fixed in a regular release coming out this summer.
...
In what version of ONTAP? I currently have an Intel based F330.No 5.0 for me... :( Or will 5.x eventually be ported to the Intel filers?
That can't be right.
We dropped new release support for the old EISA-based 486 systems (400, 450, 1300, 1400). I don't believe we dropped support for the F330.
Dave
In message 199803201613.IAA07103@jerseycity.netapp.com, Dave Hitz writes:
Okay. Our internal bug DB says that bug 4088 is open (i.e. not fixed in a regular release), but that it is in patch releases 4.3R4D2, and also that it'll be fixed in a regular release coming out this summer.
...
In what version of ONTAP? I currently have an Intel based F330.No 5.0 for me... :( Or will 5.x eventually be ported to the Intel filers?
That can't be right.
We dropped new release support for the old EISA-based 486 systems (400, 450, 1300, 1400). I don't believe we dropped support for the F330.
Just re-read the Field Alert Notice. You are correct. Which I'm very glad about. Thanks for setting me straight.
jason
On Fri, 20 Mar 1998 08:13:54 PST, Dave Hitz wrote:
Okay. Our internal bug DB says that bug 4088 is open (i.e. not fixed in a regular release), but that it is in patch releases 4.3R4D2, and also that it'll be fixed in a regular release coming out this summer.
...
In what version of ONTAP? I currently have an Intel based F330.No 5.0 for me... :( Or will 5.x eventually be ported to the Intel filers?
That can't be right.
We dropped new release support for the old EISA-based 486 systems (400, 450, 1300, 1400). I don't believe we dropped support for the F330.
NOW has 5.0 available for F200/300 series. At least, I downloaded something for my F230 that claimed to be 5.0. :)
Brett
--- Brett Rabe Email : brett@uswest.net Systems Administrator - U S West Phone : 612.664.3078 600 Stinson Blvd. Pager : 612.613.2549 Minneapolis, MN USA 55413 Fax : 612.664.4770
If you aren't the lead dog, the view is always the same.
In what version of ONTAP?
A release not yet assigned a number. The fix isn't in 5.0, unfortunately.
(We currently give releases code names until the very last minute, as Marketing has, on occasion, had the annoying habit of changing release numbers at the last minute to satisfy some odd needs of theirs - by all rights, 3.1.4 *should* have been 3.2, given that it was, as I remember, the first release on Alpha-based platforms, but something, perhaps Marketing, got in the way of rationality.
The 'toons also wanted 5.0 to be a 4.x release before I pointed out that going from one file system to N file systems was something that anybody with a brain would consider a major change....)
John F. Kane wrote:
The NOW website needs a lot of work!
No, it just needs someone dedicated to maintaining it. It took me four times to try to get the contact information corrected! When I submitted my third request, I received back a message stating that it would be updated shortly. After about two months, it was still not updated!
Does anyone else out there have problems with NetApp support? Or is it just me?
Just as an example, I called in a support issue Friday morning and was told by the NetApp support person that she needed to do a little bit of research on the issue and she would be call me back in about 15 minutes. When I hear this, I figure that it will probably be more like an hour. I never received a call back. Yes, I will be calling them again this morning.
In addition, one of my biggest pet peeves is the lack of notifications. The way I figure it, we pay for a "software subscription" but we are never informed as to when a new release is available. I would expect that a software subscription entails sending me newer versions as they become available. At the very least receive notifications (via email) that a new version is available. Even an abbreviated form of the release notes could be sent to let people know why they may wish to upgrade.
OK. Bitch mode is off now. Are there others out there that are not too happy with the support that they are receiving? -- Gerard Hickey email: Gerard.Hickey@nsc.com National Semiconductor Corporation phone: +1 207 541 6101 Advance Development Center, MS 03-03 fax: +1 207 541 6108 5 Foden Road, South Portland, Maine 04106-1706
On Mon, Mar 23, 1998 at 09:23:00AM -0500, Gerard Hickey wrote:
No, it just needs someone dedicated to maintaining it. It took me four times to try to get the contact information corrected! When I submitted my third request, I received back a message stating that it would be updated shortly. After about two months, it was still not updated!
My big issue with NetApp support is that they have TONS of bugs that are in their internal database, but yet arent on NOW. I call up NetApp, they're like "Oh, yeah that's bug xxyy". I ask "Is that on NOW?" and the engineer will say "Oh no, its not been sanitized for the web site yet."
When I've got a bug that's affecting my customers and the quality of service I'm offering, I could care less if its been "sanitized" and internal engineering comments / cuss words / etc has been removed - I want the *info available*, or at least indication that the problem *is* an acknowledged bug and NetApp is working on it, as *soon as possible*.
NetApp, if you're going to keep a list of bugs on your web page, make sure they're up-to-date, otherwise such info is useless.
I've made this request at least twice, and never heard anything of it.
The other "minor annoying" problem I've seen with the Toasters:
nfs> exit Use control-D to exit nfs> ^D Connection closed by foreign host.
Why not just use the code that is in the OS to print "Use control-D to exit" to make the filer go ahead and exit?
Bill
-- Bill Bradford Systems Engineer, Texas.Net http://www.texas.net mrbill@texas.net BeOS Developer #9630 ICQ: 1864511 --------------------------------------------------------------------- Called up the Bureau of Alcohol, Tobacco, and Firearms regional office and asked, "What wine goes best with an M-16?" The guy who answered did his best to be helpful: "That depends. What are you smoking?"
The other "minor annoying" problem I've seen with the Toasters:
nfs> exit Use control-D to exit nfs> ^D Connection closed by foreign host.
Why not just use the code that is in the OS to print "Use control-D to exit" to make the filer go ahead and exit?
Surprisingly, there's actually a good reason for this.
You can reach the toaster's admin account either through the RS-232 console, or via telnet. The picture looks something like this:
--------------- | Admin Shell | --------------- | --------- | muxer | --------- | | | | RS-232 Telnet
We did it this way so that if a customer lets NetApp people telnet in to a filer to do some administration, the customer can watch what's going on at the local console.
Anyway, the problem with "exit" is that there's no way for the Admin Shell to know whether the characters were typed from RS-232 or from telnet. (You could even type half on the console and half via telnet.)
On the other hand, the ^D can be processed right at the bottom of the muxer, where you still know which path the character came in on.
Dave
-
Bill Bradford -
Brett Rabe -
Gerard Hickey -
guy＠netapp.com -
hitz＠netapp.com -
Jason D. Kelleher -
John F. Kane