toasters

toasters@lists.teaparty.net

13520 discussions

Impact of adding disk to filer
by Frank Smith 15 Oct '99

15 Oct '99

What will happen if I add a disk to a volume (NetApp C720)? I learned the hard way that adding the drive to the shelf interrupted all NFS ops for 15 seconds, the docs said it would take that long to add it as a hot spare, but didn't mention that the filer would completely freeze while it did it. If I add a disk to a volume, what will it do to performance, and for how long? I don't mean long-range gains from having the data spread over more spindles, I mean what immediate impact will it have on current NFS clients. Will it just be a temporary increase in CPU as it spreads the data or will it freeze for some period of time, and if so for how long? Current sustained load on the filer is several hundred NFS ops/sec, and any pauses cause significant problems on the client systems, so I want to have a better understanding of what will happen when I give the vol add command before I actually do it. Thanks, Frank -- Frank Smith fsmith(a)hoovers.com Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501

4 3

RE: Forcing a halt/reboot without "halt -d"
by David Stack 12 Oct '99

12 Oct '99

We had this same problem in the past (coincidence that we both work for the same company?) and were told that it was bug 10186. We're now running version 5.2.3D1 and haven't had the problem in a month or so. Dave **************************************************************************** ************* EMail: dstack(a)nortelnetworks.com Phone: 403-232-4752 Fax: 781-8850 ESN:765 Addr : Nortel Networks; 2924 11 St. NE; Calgary, AB; T2E 7L7;Canada **************************************************************************** ************** > -----Original Message----- > From: Luke Mewburn [SMTP:lukem@goanna.cs.rmit.edu.au] > Sent: Tuesday, October 12, 1999 8:47 AM > To: Arden, Bruce [HAL02:8883:EXCH] > Cc: toasters(a)mathworks.com > Subject: Re: Forcing a halt/reboot without "halt -d" > > "Bruce Arden" writes: > > I have just had to reboot our filer for the second time in about 3 > > months. Both times the reboot failed with the error: > > > > A CIFS I/O operation may be hung. Shutdown the system using halt > > -d > > and report this incident to NetApp. > > > > But I don't want to do a "halt -d". This causes a core dump which > > means that the filer may be down for about 10 mins. Is there a way > > of forcing a halt without using the -d switch (halt on its own just > > gives the CIFS error message again). I'm currently running 5.3.1D5. > > > > - Bruce > > > > PS The problem that caused me to reboot was that I was getting the > > error "Cannot find logon server" from PCs trying to connect to the > > filer. The reboot fixed this. Any ideas? > > A suggestion which won't solve your problems, but may help the boot > time: move savecore to the end of /etc/rc; it speeds up availability > after a boot at the potential expense of corrupting your coredump. > > PS: I have seen the ``can't halt because filer is wedged on CIFS > users'' problem on older 5.x releases (can't remember exact numbers), > but I think we've been OK since 5.3 (now running combination of > 5.3D19 and 5.3.2D4, with the latter on our more loaded systems). I > know this contradicts your experience (since you're running 5.3.1D5), > but you never know; 5.3.2Dx may have fixed something related to this. :-/

5 4

Re: Forcing a halt/reboot without "halt -d"
by Luke Mewburn 12 Oct '99

12 Oct '99

"Bruce Arden" writes: > I have just had to reboot our filer for the second time in about 3 > months. Both times the reboot failed with the error: > > A CIFS I/O operation may be hung. Shutdown the system using halt > -d > and report this incident to NetApp. > > But I don't want to do a "halt -d". This causes a core dump which > means that the filer may be down for about 10 mins. Is there a way > of forcing a halt without using the -d switch (halt on its own just > gives the CIFS error message again). I'm currently running 5.3.1D5. > > - Bruce > > PS The problem that caused me to reboot was that I was getting the > error "Cannot find logon server" from PCs trying to connect to the > filer. The reboot fixed this. Any ideas? A suggestion which won't solve your problems, but may help the boot time: move savecore to the end of /etc/rc; it speeds up availability after a boot at the potential expense of corrupting your coredump. PS: I have seen the ``can't halt because filer is wedged on CIFS users'' problem on older 5.x releases (can't remember exact numbers), but I think we've been OK since 5.3 (now running combination of 5.3D19 and 5.3.2D4, with the latter on our more loaded systems). I know this contradicts your experience (since you're running 5.3.1D5), but you never know; 5.3.2Dx may have fixed something related to this. :-/

3 2

Forcing a halt/reboot without "halt -d"
by Bruce Arden 12 Oct '99

12 Oct '99

I have just had to reboot our filer for the second time in about 3 months. Both times the reboot failed with the error: A CIFS I/O operation may be hung. Shutdown the system using halt -d and report this incident to NetApp. But I don't want to do a "halt -d". This causes a core dump which means that the filer may be down for about 10 mins. Is there a way of forcing a halt without using the -d switch (halt on its own just gives the CIFS error message again). I'm currently running 5.3.1D5. - Bruce PS The problem that caused me to reboot was that I was getting the error "Cannot find logon server" from PCs trying to connect to the filer. The reboot fixed this. Any ideas? -- Bruce Arden arden(a)nortelnetworks.com Nortel, London Rd, Harlow, England +44 1279 40 2877

2 1

Re: Autosupport, 5.2.3 upgrade, diskscrub and wackz
by sirbruce＠ix.netcom.com 12 Oct '99

12 Oct '99

On 10/11/99 07:41:30 you wrote: >The volume could be offline, that's for sure, but why the machine ? This is the result of a less-than-thorough multivolume implementation plan. Originally, there only *was* one volume, so taking the whole filer down wasn't an issue. Presumably when mutlivolume was to be implemented, Netapp decided it was more important to get that out the door than to spend more time and resources modifying a better wack interface to run on an offline volume while the system remained up. Note that this is also different from a request for a completely online wack on an active filesystem, or allowing a filesytem to remain online read-only while being wacked. I still question the utility of the latter, but it might be good as part of an automated process strategy (just as snapshots are created for dump). Anyway, these are all very different enhancements. Netapp will have to decide which ones to implement, and which ones to implement first. Bruce

2 1

Client pack fo NetApp - implementation ???
by Itzik (Itzhak) Meirson DSc 11 Oct '99

11 Oct '99

I wonder how is the backup performed by the new client for NetApp... 1. Is the backup done from a special snapshot or from the "live" files? 2. When defining the NetApp client what directive should be used? I might have missed this information from the docs I have seen. Thanks in advance, Itzik

1 0

Re: Autosupport, 5.2.3 upgrade, diskscrub and wackz
by sirbruce＠ix.netcom.com 11 Oct '99

11 Oct '99

On 10/10/99 12:12:52 you wrote: > > "sirbruce" == sirbruce <sirbruce(a)ix.netcom.com> writes: > > sirbruce> The problem is that with a changing filesystem, such > sirbruce> programs could easily report a problem when in fact > sirbruce> there is none. There are some ways around this. > >Huh? If the filesystem is made immutable, it isn't a changing >filesystem. e.g, on a Unix host, this _should_ be safe: > >unmount filesystem. >mount filesystem read-only. >run fsck on filesystem. >remount filesystem read-write. Sure, but for many environments, read-only is not an option. It may be for you, but for others it's still downtime. >Why should I expect downtime? A failed disk is a problem, but it >doesn't cause downtime. A failed power-supply is a problem, but it >also doesn't cause downtime. A failed head is a problem, but in a >cluster, no downtime (well, 60 seconds downtime). NA has designed the >filer to stay up in the face of these problems. So if NA has a check >list of problems and it is working its way down the check list to keep >filers up in the face of these problems, then "file-system >health-check and fix" needs to be added to that list. Sure, it isn't a >common occurance, but clearly it happens often enough for NA to have >written wack and constantly improved it over the years. I'm arguing >that the next improvement is to allow wack to be run on an on-line >filer. Upgrading your software/firmware/disk firmware is more common. So is adding new cards into the system. Yet you expect downtime on those. So if what was most common was the measure of importance, then these should be worked on before an on-line wack. I agree online wack is a good thing to have, but I guess I'm satisfied in seeing Netapp concentrate on other bugs and features first. I wasn't arguing that it shouldn't be done. Bruce

4 3

Re: Autosupport, 5.2.3 upgrade, diskscrub and wackz
by sirbruce＠ix.netcom.com 11 Oct '99

11 Oct '99

On 10/10/99 02:59:52 you wrote: > > "alexei" == alexei <alexei(a)mindspring.net> writes: > >> this rather distressing. The filer really needs a way to perform a >> filesystem health check w/o downtime. > > alexei> Like running fsck on a mounted filesystem? Some things are > alexei> better done in a quiesced state... > >The filer is not a Unix host serving NFS. I expect more out of it. I >didn't say it needed to correct errors while serving content, I said >it needed to be able to do a health-check. If you go back to my >original message, I mentioned that if it required an immutable >filesystem to do this, then you should be able to tag a filesystem >(not just an export) read only. The raid scrubbing is indeed meant to be such a check, although it is not filesystem-based. >You can btw, run fsck on a mounted filesystem. Solaris happily runs >'fsck -n' on a mounted file system (yes, I know, it will also happily >run 'rm -rf /' which doesn't mean you should do it - lot's of rope and >whatnot). Linux will run e2fsck after making some noise. I don't see >any reason why this would be dangerous on a filesystem mounted read >only. The problem is that with a changing filesystem, such programs could easily report a problem when in fact there is none. There are some ways around this. Personally, while I think this should be on Netapp's agenda, there are more important things as well. Wack has been improved and now runs much faster than before. You should expect some downtime to happen when problems occur; having parity inconsistencies is *not* a normal occurrance and should not happen often. Bruce

3 2

Releasing file locks on the Netapp
by Brian Tao 10 Oct '99

10 Oct '99

Is there a way to force the Netapp to forget about specific locks? I know how to get the Netapp to forget about *all* locks from a particular client, but I don't always want that. My specific problem is with the FrontPage extensions on Solaris (using Apache as the web server). Once in a while, the extensions think there is another instance running. It determines this by attempting to lock a file called vti_pvt/service.lck . I can run lock_dump on the Netapp and see the inode and client- side pid that was granted the lock, but in some cases that pid is no longer extant. All the FP documentation I've seen says "kill off the hung process", which doesn't apply here. I've been able to work around the problem each time simply by renaming/removing the service.lck file, but I thought I should at least investigate the possibility of removing entries from the Netapp's table of locks. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Re: Autosupport, 5.2.3 upgrade, diskscrub and wackz
by alexei＠mindspring.net 10 Oct '99

10 Oct '99

Jay Soffian <jay(a)cimedia.com> writes: > Do parity errors during a disk scrub necessarily indicate something is > wrong with the filesystem? Not neccessarily. > this rather distressing. The filer really needs a way to perform a > filesystem health check w/o downtime. Like running fsck on a mounted filesystem? Some things are better done in a quiesced state... >NA also needs to publish > accurate timing data on wack via NOW. The only document I can find has > ancient data. There are way too many variables to that equation. It depends on the version of the OS, the version of wack, etc. I have seen times when running the incorrect version of wack yielded 3 hour wack's (before someone mentioned this should not be the case; we restarted with the proper version). A similar table that would be nice is raid reconstruct speeds based on volume size, filer load and disk size. Now that would be interesting.. :) Alex

3 2

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