toasters

toasters@lists.teaparty.net

13520 discussions

Dual power on F760
by Aaron M. Sims 11 May '99

11 May '99

I've scanned the docs and the now.netapp.com site for an answer to this... no luck. How do I determine the status of either power supply in a F760 filer. If a power supply is off or failed, I'd like to run a command that will tell me just that. Thanks, Aaron -- Aaron M. Sims | "The reason why bad things happen to you is BellSouth.net | because you're a dumbass!" Systems Engineer | - Red Foreman, That 70s Show aaron.sims(a)bellsouth.net|

3 4

Re: rsh into the filer from NT
by Matt Day 10 May '99

10 May '99

Jason Middlebrooks <Jason_Middlebrooks(a)datalink.com> wrote: >I was told by someone that you can not rsh into a filer from the builtin >rsh utility NT has to offer. Am I correct on this one and is there a third >party rsh utility that will allow me to do this? I know it works great in >the UNIX evironment. No, that's not true. NT's builtin rsh works fine with the filer. Matt

1 0

RE: rsh into the filer from NT
by Benn, Paul 10 May '99

10 May '99

Hi Jason, Yes, rsh CAN be used on an NT box to issue commands to a filer. I recently released a white paper that has a section on using rsh. Check out Section 5.2 of: http://www.netapp.com/technology/level3/3052.html Hope this helps. Regards, Paul -----Original Message----- From: Jason Middlebrooks [mailto:Jason_Middlebrooks@datalink.com] Sent: Monday, May 10, 1999 2:46 PM To: toasters(a)mathworks.com Subject: rsh into the filer from NT I was told by someone that you can not rsh into a filer from the builtin rsh utility NT has to offer. Am I correct on this one and is there a third party rsh utility that will allow me to do this? I know it works great in the UNIX evironment.

1 0

rsh into the filer from NT
by Jason Middlebrooks 10 May '99

10 May '99

I was told by someone that you can not rsh into a filer from the builtin rsh utility NT has to offer. Am I correct on this one and is there a third party rsh utility that will allow me to do this? I know it works great in the UNIX evironment.

1 0

RE: Ontap P* relase mess.
by sirbruce＠ix.netcom.com 07 May '99

07 May '99

On 05/07/99 12:09:23 you wrote: >[process details snipped] >We are just beginning to move to this new model. There is likely to be some >overlap between P releases and maintenance releases in the near term. I hope you >can bear with us as we work through this transition. Well, the new process looks more efficient and sensible, but basically it amounts to eliminating P releases and putting out regular maintence releases. This is fine, but it doesn't really eliminate the problem this particular custoemr had. In the new scheme, CS would have given this customer a 5.2.1Dx patch which they'd be using when 5.2.2 came out. Due to the timing constraints you mention, the D patch might not have made it into the 5.2.2 release. The new customer, seeing 5.2.2 (either on a new filer or on NOW) assumes 5.2.2 would include 5.2.1Dx, and so downloads it and gets bitten. This was what prompted me to suggest what I did before. In the new scheme you describe, since CS can spin a D release quickly to address a customer problem, when 5.2.2 is ready for release it can be delayed only a day or two for CS to spin any Ds it needs from 5.2.1 to go with 5.2.2 that didn't make it into 5.2.2. Then when the customer running 5.2.1Dx goes to NOW, they'll not only see 5.2.2, but 5.2.2Dx with a note only to download this version if they're running 5.2.1Dx. Of course, if CS really can't spin a release that fast, then okay. But I suspect this might be what will wind up happening anyway. A customer experiences one bug, which CS fixes in 5.2.1Dx, then another bug which is fixed in 5.2.2. CS will have to spin a 5.2.2Dx release before 5.2.3 (which hopefully finally contains the 5.2.1Dx patch missing in 5.2.2) >I also agree with Paul regarding the rfe's. We need to do a better job of >documenting the changes that go into these releases. Customers need accurate >information about the content of these releases in order to make informed >decisions in managing their filers. You should expect to see change here as >well. Yes, barring any other corrective action at least this will provide another way an otherwise confused customer can learn not to install a certain version because the patch they want isn't in it. Bruce

1 0

Re: Dual power on F760
by sirbruce＠ix.netcom.com 07 May '99

07 May '99

On 05/07/99 16:02:32 you wrote: > >Well, here's my delima. The filer is isolated (network wise) and >has no default route to the rest of the world. SNMP won't help. > >The filer is in a remote location (800 miles away), so looking >at the LED is not a viable option. I think that even when one power supply fails and the other takes over, it will log a message in the messages file (and on the console). This may be one of those "log once every hour" messages so the customer can't miss it. So if you don't have those, I think the power supplies are OK. The message may not tell you which power supply is bad, but that's what the LED is for, since you have to have someone there in person to replace it. Bruce

1 0

RE: Dual power on F760
by Jonas Jonsson 07 May '99

07 May '99

Hmm, We have a customer that have been testing this all week. Lots of mails and SNMP traps sent all over the net. Also the LED will show this info. /// Regards, Jonas Jonas Jonsson phone: +46-8-623 65 82 Proact Datasystem AB mobile: +46-709-42 13 67 Djupdalsvägen 7 mail: jonas.jonsson(a)proact.se Sollentuna, Sweden -----Original Message----- From: Aaron M. Sims [mailto:ams@bellsouth.net] Sent: Friday, May 07, 1999 8:24 PM To: toasters(a)mathworks.com Subject: Dual power on F760 I've scanned the docs and the now.netapp.com site for an answer to this... no luck. How do I determine the status of either power supply in a F760 filer. If a power supply is off or failed, I'd like to run a command that will tell me just that. Thanks, Aaron -- Aaron M. Sims | "The reason why bad things happen to you is BellSouth.net | because you're a dumbass!" Systems Engineer | - Red Foreman, That 70s Show aaron.sims(a)bellsouth.net|

2 1

RE: Ontap P* relase mess.
by Hibbard, Ken 07 May '99

07 May '99

|Hey, the process can always change. :) I was mostly just |guessing given the circumstances, and knowing that Netapp |wouldn't not include the patch without a reason. | Bruce, Change is coming. Hopefully for the better but you can be the judge of that. Netapp is moving to a new software release model. This is motivated by a need to correct some of the deficiencies in our current model. Also, as our customer base continues to grow we believe we need a more scalable and predictable approach to patch and maintenance releases. Let me give you a brief summary of the current model and where we are going with this new process. In the past, engineering was responsible for major and minor features releases. These releases went through the full engineering development and QA process. The customer engineering (CS) team had responsibility for the P releases and D patches. D patches were generated to fix a specific customer reported problem. P releases were a roll-up or collection of D patches that were judged to be valuable to a larger set of customers. For a variety of reasons we are moving to a model were engineering will be responsible for feature releases *and* maintenance releases. Maintenance releases will be scheduled at regular intervals (approximately 3 months) and go through the full engineering development and QA process. The CS team will continue to generate D patches for specific customers reported problems. We will make every effort to incorporate all outstanding D patches into the next available maintenance release. (There will be a time window where this is not possible. D patches that are generated in the latter phase of maintenance release testing may be difficult to integrate at the 11th hour. We also don't want to delay the scheduled release of the maintenance release. The predictability is important.) Maintenance releases will be cumulative with respect to the bug fixes they contain. For example, X.2.3 should be a superset of X.2.2. We believe there is a good case to schedule these releases at regular intervals We appreciate the fact that upgrades are disruptive and time consuming. Predictable releases allow our customers to plan for these upgrades. It is also important that the release numbering system be clear and meaningful to customers. Our current D/P number is not always intuitive. We are just beginning to move to this new model. There is likely to be some overlap between P releases and maintenance releases in the near term. I hope you can bear with us as we work through this transition. I also agree with Paul regarding the rfe's. We need to do a better job of documenting the changes that go into these releases. Customers need accurate information about the content of these releases in order to make informed decisions in managing their filers. You should expect to see change here as well. Thanks, Ken

2 1

Re: Ontap P* relase mess.
by sirbruce＠ix.netcom.com 07 May '99

07 May '99

On 05/06/99 14:56:52 you wrote: >So it looks like I'm going to have to downgrade to 5.2.1P2 from 5.2.2 to >avoid panics from assertions in the netbios name service.. Patches for >5.2.2 are somewhere in the indeterminate future.. (all of this for bug >12712, which for some reason isn't listed in Bugs Online) I agree... many bugs are missing from Bugs Online and the bugs are not updated often enough. Perhaps the people making patch releases don't have full power to update Bugs Online as part of the patch making and bug reporting process. >This brings up one of the points that Tom (?) was ranting on a week or so >ago.. Why release 5.2.2, a minor bug-patch revision, that don't >incorporate patches from its predecessor? My guess is something like this. When 5.2.1 was released, naturally 5.2.2 was already being considered and worked on. Shortly thereafter it probably went into testing. During 5.2.2 testing, some bugs cropped up in 5.2.1. Various patch releases were created to fix some of the problems. However, they did not get as extensive testing as a full "dotdot" release. No doubt someone wanted to roll the P2 patch into 5.2.2, but someone else said it was already too late and doing that would require testing all over again. This was probably unnaceptable for some political reason - anything from something minor like not wanting to slip on the schedule to something major like something in 5.2.2 that some big customer needs and said big customer not being likely to encounter bug 12712. >Perhaps I shoud've called support first, but I just brought these 760's >online with 5.2.2, under the apparently false impression that I was >getting all the up-to-date fixes.. Was there an erratta for 5.2.2 that I >missed that said "THE FOLLOWING IS STILL BROKEN:"? Would be nice if they had listed known bugs in 5.2.2. Bruce

2 1

A few general bitches and moans.
by Jaye Mathisen 07 May '99

07 May '99

I've been moving around some of our applications to make better use of our netapps and storage, and as part of this shuffle, some things just gotta be said... (I will preface this by saying that I really like my filers, both of them work very well in terms of reliability, it is just the nature of the beast to criticize when something doesn't work like you want it to, and be silent when it's doing its job. :) o The lack of *good* automated, filer-sufficient backup and management tools. NDMP is fine, but the *filer* needs to truly be an appliance, and needs to be able to do this on its own. No rsh monkeying around, just nice consistent, in-the-background, web-managed backup. Follow a schedule, run some "scripted" jobs, SMTP/SNMP trap the results. Not rocket science. o The lack of widespread tape changer support, or at least tweakable changer support. For various reaons, one of my filers will have 2 ADIC DLT tape changer systems on it, which doesn't do me a speck of good from the filer side, as I still have to issue the commands to swap tapes around. Gag. o CIFS support has got some big holes. - The inability to belong to multiple domains. Not all my domains trust each other. Oops, now the filer is essentially unusable for some of them. - For me, at least, CIFS management with no PDC is non-intuitive at all. I would pay real money for somebody to explain to me how to use autoexnt, a filer with no PDC and no WINS access, and permanently affix a share that is usable by more than one person. I can mount the share in autoexnt, but it's not accessible to anybody. (I use autoexnt with the interactive option, and the connection is successful, yet I always get "access denied" when trying to access it. However, if I attach it with the same login account as the autoexnt service, with the same username/password pair, it's fine. The CIFS tracer thingie on the Netapp tells me that both accesses are being mapped to the same Unix user account, but one works, the other doesn't... I have mailed support this one, but nary a response... - Even the ability to have a different network interface belong to a different domain would be useful. Not a panacea, but at least useful. o The general suckiness of NFS now being insufficient to backup the filer with CIFS. Probably not a solveable problem, but it still sucks. o The apparent lack of CIDR support in routing tables. I realize that routing requirements for a filer are probably not super significant, but something better than /24 would be nice. o NOW is better, but quicker navigation tools would help. I also do not understand why documentation requires a NOW login. o I would give a body part for a small filer, with 3 18 or 36GB drives, self contained, no shelves. Medium performance, medium capacity, hot swappable, 1 100MBit ethernet port, just plug and go. 8MB NVRAM, 256MB RAM. I hate adding file servers for that niche where even a small 720 is physically too much hassle, and the price-point is out the roof. Make the drives user-supplied, off a netapp recommended list, and kaching, give me an even dozen. Maybe leave in a slot for a 5 1/4" Tape drive. Heck, I saw some very scary numbers from consensys for their IDE raid product, use IDE drives instead of scsi in this bad boy, and cut them costs down. WD makes 7200 RPM drives now, at 18GB's a pop, and 5 of 'em fit in a 3 high bay. (And no, I'm not interested in the philosophical war of IDE vs SCSI. Fact: IDE is currently cheaper than SCSI. Fact: I want this box to be cheap. Check and mate. :)) o It would be cool if config information, perhaps even the OS was on a optional PCMCIA card, that was formatted in a fashion readable on a notebook. Nothing like not having the right serial cable wired up, and having to type all those stupid commands by hand when you make a booboo, and plus the grief of having to boot off two floppies. o Or add an option to read rc from disk 3 on a DOS formatted floppy. o Fine, you don't want to use something like PCMCIA cards, then since Netapp only allows its network cards, allow tftp of the rc file from one of the interfaces. I guess the CIFS stuff is what's torquing me off right now the most, I don't want to have to slap a bunch of storage on some NT boxes when I have this filer sitting there perfectly suited (in theory) to do the job..., and I refuse to purchase 1 filer per domain.

6 7

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