toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

RE: disk_fw_update issue with 840-5.3.7R2
by Tom "Mad Dog" Yergeau 08 Jan '01

08 Jan '01

SnapMirror wouldn't work for what I've suggested as it is read-only asynch. A read/write synchronous mirror (i.e. RAID 4+1) would be required for what I suggested. Also, to avoid disruption to the client systems, the CIFS share name or NFS export could not be changed during the fw_update, so it would have to be the same set of data and not a snapmirror. Thus even a synchronous snapmirror wouldn't work, unless you could make the snapmirror read/write, re-direct clients to the mirror on the fly without breaking the TCP session, and then reverse-synch once the disk_fw_update was done and put the clients back on the original disks. That'd be quite a trick! Think 99.999% uptime, no disruption to clients for *ANYTHING*. Or at least nothing as common and (relatively) trivial as a firmware update. I'd still say NetApp should look at ASUP logs and pre-flash replacement disks to the level appropriate for your ONTAP version before shipping them to you. That's probably a lot easier to do in the short term than my ambitious on-the-fly firmware update suggestion. :) Hey--here's a technical question. SCSI RAID systems allow you to update the firmware on one disk without disruption I/O to the other disks. Is this possible on an FCAL loop? Or is the whole idea technically infeasible due to limitations in FCAL? MD -----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Monday, January 08, 2001 2:21 PM To: Tom "Mad Dog" Yergeau; 'Krause, Oliver'; toasters(a)mathworks.com Subject: Re: disk_fw_update issue with 840-5.3.7R2 > It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets > this would be a real piece of cake. Just flash half a mirror while the > other half served data. Have you heard of something called SnapMirror? Bruce

1 0

RE: disk_fw_update issue with 840-5.3.7R2
by Tom "Mad Dog" Yergeau 08 Jan '01

08 Jan '01

Just upgrading one disk still takes downtime for the whole system. The filer may be up, but if I can't access my data, effectively, it's down. "Downloading disk firmware can be disruptive to the system. It involves spinning down and then spinning up all affected disks, and suspending all disk I/O to all disks while that is happening. This may take up to 2 minutes to complete. This delay may cause clients to hang, and may cause CIFS clients to drop sessions." It should be noted that this notice can be misleading. It actually takes up to two minutes PER TYPE OF DISK to complete a disk_fw_update. So if you have two models of 18 GB drives and two models of 36 GB drives, if can take up to eight minutes to flash the firmware. Been there, done that. Was a little surprised the first time. :) Since replacement disks often ship with firmware different than the level currently being used on a filer, it would be nice if (a) NetApp checked autosupport logs and pre-flashed the firmware for you before sending you the disk (b) You could flash a single disk w/o disrupting all I/O for the entire filer. Especially if the disk is marked as a spare and therefore not part of any volume. If NetApp wanted to get *really* ambitious (I dunno, for ONTAP 6.5 or something), this would be wild: flash firmware on a volume one disk at a time, and keep the volume online. While each disk is being flashed, use the parity disk to serve data, and keep track of writes somewhere to get the flashed disk back up to synch when the flash is done. It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets this would be a real piece of cake. Just flash half a mirror while the other half served data. Online disk_fw_update would be a big help in five 9s environments. MD -----Original Message----- From: Krause, Oliver [mailto:OKrause@netapp.com] Sent: Saturday, January 06, 2001 5:56 AM To: 'Premanshu Jain'; 'toasters(a)mathworks.com' Subject: RE: disk_fw_update issue with 840-5.3.7R2 You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

2 1

Preposterous date/time stamp
by Thomas.L.White＠chase.com 08 Jan '01

08 Jan '01

I seem to recall reading about this on the list - but could not find any related emails. Does anyone know of a bug and or fix for the date stamp on files/directories on the filer showing up as 20 to 30 years in the future ? The users are still being migrated to the filers from their old Novell or NT "homes" so this may even be due to "copy method" I'm not sure at this point We have not managed to replicate the error on "command". thanks tw

1 0

RE: 72 Gig disks
by Mohler, Jeff 08 Jan '01

08 Jan '01

Like anything else, the sizing you are looking at for HDs can affect performance depending on what your application and read/write requirements/habits are. Its inaccurate to state "performance problems" as a global issue as "performance" means different things to different customers. Consult with your salesperson and thier SE..they will be glad to help you make the best decision to match your specific environment, or follow this thread..im sure we'll get into a healthy debate on this. *grin* Cheers!

3 4

disk_fw_update issue with 840-5.3.7R2
by Premanshu Jain 07 Jan '01

07 Jan '01

I have a 840 cluster. Whenever I add new disks, the cluster starts throwing 'doenrev disk firmware' error messages. NetApps suggests doing a disk_fw_update on the disk and strictly says "NO need to Halt a filer'. Reality is totally different. The command specifically asks you wether the cluster partner is on Halt-OK prompt or not? The workaround I am doing, intitiate a takeover and do the disk_fw_update. However, this still needs to do a takeover/giveback and 2 minutes of downtime...Adding/replacing bad disks is a regular activity... Any suggestions..?

3 2

RE: disk_fw_update issue with 840-5.3.7R2
by Krause, Oliver 06 Jan '01

06 Jan '01

You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

1 0

RE: 72 Gig disks
by Klinkner, Steve 05 Jan '01

05 Jan '01

> -----Original Message----- > From: Thomas Heffron [mailto:theffron@wisedata.com] > 2) They are not listed in the drop down when creating a generic volume in > the GUI (at least in 5.3.6 - don't know about 6.x). This is fixed in a 6.x point release that should ship in the next few months (bug is 28306). In a future release, the pull-down will display only a list of spare sizes which actually appear on the system (which in all cases makes more sense than the canned list it currently displays). ---------------------------------------------------------------------- steve klinkner klink(a)netapp.com

1 0

72 Gig disks
by Geoff Hardin 05 Jan '01

05 Jan '01

Anyone hear anything about the status of the 72 gig disks? We're trying to plan for the upcoming year whether we want to get more disks (18's & 36's), new disks (72's), more filers, etc. A quick search of NOW didn't turn anything up. -- Geoff Hardin Dallas Semiconductor MIS UNIX geoff.hardin(a)dalsemi.com

4 3

RE: 72 Gig disks
by Kitch, David 05 Jan '01

05 Jan '01

They're available on the new systems, but they don't recommend them for performance reasons. Regards, David Kitch Texas Instruments Incorporated IS dkitch(a)ti.com -----Original Message----- From: Geoff Hardin [mailto:geoff.hardin@dalsemi.com] Sent: Friday, January 05, 2001 1:29 PM To: toasters(a)mathworks.com Subject: 72 Gig disks Anyone hear anything about the status of the 72 gig disks? We're trying to plan for the upcoming year whether we want to get more disks (18's & 36's), new disks (72's), more filers, etc. A quick search of NOW didn't turn anything up. -- Geoff Hardin Dallas Semiconductor MIS UNIX geoff.hardin(a)dalsemi.com

1 0

RE: Slooow SGI Challenge
by Fox, Adam 04 Jan '01

04 Jan '01

Personally, I'm a big fan of packet traces. They can tell you alot. In this case, you have one good performing client, and one bad one. Take a packet trace of each and compare them. What sizes are the clients requesting? What calls are they using? Is the client just not generating requests very quickly? Just some thoughts.. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: Link, Bill (OTS-EDH) [mailto:Bill_Link@billing.com] > Sent: Thursday, January 04, 2001 4:57 PM > To: 'toasters(a)mathworks.com' > Subject: Slooow SGI Challenge > > > > Has anyone had any experience with netapp on an SGI Challenge system? > > I have an F760 attached through a cisco 4000 switch to an sgi > challenge and > an IBM S7A. I have this arrangement on a dedicated subnet with all > interfaces set manually to 100tx. (The vme controller in the > SGI will not > abide full duplex). The netapp is running 5.3.6R1, the SGI is > running IRIX > 6.5.5, and the RS6K is running AIX4.3.3. > > The IBM will create a 128M file in under 30 sec. If I mount > the filer on the > SGI box and specify tcp it takes about 2 min 45 sec to write > the same file. > If I let the mount on the SGI default to udp it won't write > more that 15 or > 20 mb before it starts getting nfs timeouts. The filer seems > oblivious to > any trouble that the sgi is having. The sgi will work > (slowly) at 10mb half > duplex with udp. > > Any suggestions would be much appreciated. > > Bill Link > SysAdmin > Output Technology Solutions > bill_link(a)billing.com > >

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