toasters

toasters@lists.teaparty.net

13520 discussions

Re: Upgrading from an F330
by mds46523＠ggr.co.uk 17 Nov '97

17 Nov '97

Here's the idea we like the most round here, but it takes investment. Be persuasive with your salesguy and arrange for a newer box, F520 say, spec'd to cope and arrange for a decent overlap between setting up the new system and taking the old one away - if you get some kinda upgrade deal that is. Sounds like you could probably use a nice stable F330 elsewhere anyway so you might keep the old box too. 8) Use NDMPCopy 1.1 (with DOT4.3 I think) to do a big copy of all the data when things aren't too exciting on the network or the filer. Either that or use a full backup on tape to copy the bulk of the data. (presupposing you take local backups like we do, which most people appear not to for some reason) When you get your chance to actually do the switcheroo take the F330 offline wrt the clients, do a final incremental to the new box over the network, make the new box look like the old one to the world (and make the old one look like something else...too) and do a bit of testing from your clients. If all seems stable at that stage then run with it in full-production style. If problems crop up, you can breath a sigh of relief that all the old data is still safe and instantly accessible on the old filer and deal with things as they happen. If you've gotten through your first, say, couple of weeks then you can have high confidence that the new filer won't give out on you. Certainly this is pretty much how things have worked when we've upgraded our filers here (and believe me, I've now upgraded 8 in different and *interesting* ways). The real enabler for us to do the job without threatening the data (the important stuff after all) was that our NetApp engineers let us sit on kit when things looked dicy and gave us excellent support in putting the boxes together and dealing with the bedding-in problems. I could tell you tales of the late nights they've put in completely stripping down and rebuilding cabinets full of kit... All you need is the option to backout and suddenly going forward doesn't seem quite so nerve-wracking. Plus the visible downtime of the data can be cut to minutes if you have the details down pat. Hope this helps. On Nov 15, 9:39, Daniel Quinlan wrote: > Subject: Upgrading from an F330 > One of our filers, an F330, is very overloaded (80-100% CPU usage and > 1000-1500 NFS ops/sec for most of the 24 hour day) and is always very > close to being full. Both shelf pairs are full of 4 GB disks. We > also have an F540 and an F630, which are far less loaded. > > Interestingly, the F330 is the most stable filer we have had: no disk > failures in over a year, no major problems. I wish our other filers > were so rock solid. *sigh* Our other two filers have had so many > problems, I can't remember them all: failed disks, failed ethernet > transceiver, bad shelves, SCSI problems, etc. > > Unfortunately, the data on the F330 is some of most critical data at > our company. More than a few hours of downtime is *not* an option. > > I read Tom Yates's "migrating an F330 to a mixed-disc configuration" > messages, so I'm not really inclined to try that. Are there any other > options for fixing the performance and disk space problem that you > would recommend? > > - Dan >-- End of excerpt from Daniel Quinlan -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

Re: Experiences with CIFS
by sirbruce＠ix.netcom.com 16 Nov '97

16 Nov '97

On 11/12/97 09:36:10 you wrote: >CIFS is new to the NetApp boxen and it seems to work pretty well, but >NFS was your first baby and you have not done anything yet to help us >in this world who need one item - soft quotas. There may be some confusion as to *exactly* what you mean by soft quotas, and how they work. Someone once asked me that the next time someone mentioned this, to ask them to PLEASE explain what you expect the soft quotas to do, how they work, and how they currently work on your other (say, Sun) machines. Bruce

9 16

Upgrading from an F330
by Daniel Quinlan 15 Nov '97

15 Nov '97

One of our filers, an F330, is very overloaded (80-100% CPU usage and 1000-1500 NFS ops/sec for most of the 24 hour day) and is always very close to being full. Both shelf pairs are full of 4 GB disks. We also have an F540 and an F630, which are far less loaded. Interestingly, the F330 is the most stable filer we have had: no disk failures in over a year, no major problems. I wish our other filers were so rock solid. *sigh* Our other two filers have had so many problems, I can't remember them all: failed disks, failed ethernet transceiver, bad shelves, SCSI problems, etc. Unfortunately, the data on the F330 is some of most critical data at our company. More than a few hours of downtime is *not* an option. I read Tom Yates's "migrating an F330 to a mixed-disc configuration" messages, so I'm not really inclined to try that. Are there any other options for fixing the performance and disk space problem that you would recommend? - Dan

1 0

subscribe toasters
by Waiming Mok 14 Nov '97

14 Nov '97

subscribe toasters

1 0

Re: "fchown: Not owner" errors between Digital Unix 4.0b ftpd and filer
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

On 11/13/97 12:25:56 you wrote: > >Greetings, > >We operate an anonymous FTP service using the wuarchive FTP daemon >(wu-2.4.2-academ[BETA-13]) on an Alpha running Digital Unix 4.0b. The >files are stored on a filer running 4.0.1c. > >>From time to time we set up anonymous FTP groups, so remote anonymous >users can supply a group password to gain special access to normally >inaccessible areas. When the FTP data area was on a local file system >on an OSF/1 3.2 system, people could use this group access to upload >files onto the FTP server. Now that we have upgraded the OS and moved >the data to a filer, attempts to do this result in the error > 550 fchown: Not owner. > >and a 0-length file on the filer. > >Can anybody shed light on why this might be happening? I ran into a similar problem with BSD/OS doing the same thing. It seems to be like it changes the group first, and then this results in the writes failing when it goes into "normal" permission mode. But it did not occur from a Solaris client. I didn't get a packet trace at the time, so I couldn't figure out if it was a problem with the filer, the OS, or in the way wuftpd is coded. Never tired Digital Unix, but if it's in there, then it is probably worth the time for Netapp to investigate this and determine exactly where the problem lies. Bruce

2 1

F220 needing upgrade
by fred.abounader＠vantis.com 13 Nov '97

13 Nov '97

Situation: I have an F220 with 2 shelves all slots full with 4G drives. I need to more disk space. Problem(s): An F220 can only accomodate 2 shelves. Possible Solution 1: Make the F220 an F330 with an F330 spares kit and add 2 more shelves and drives. Questions: Does anybody have any Storage Work shelves (BA35X-MD-2X) they want to unload? Do I want to mix 9G drives (in the new shelves) with the existing 4G drives (in the existing shelves)? Any other concerns???? Thanks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Fred Abounader Vantis (AMD's PLD Subsidiary) ~ ~ email: fred.abounader(a)vantis.com Mailstop 546 ~ ~ voice: (512)-602-1644 5300 E. Ben White Blvd. ~ ~ FAX: (512)-602-4148 Austin, TX 78741 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

"fchown: Not owner" errors between Digital Unix 4.0b ftpd and filer
by Mic Kaczmarczik 13 Nov '97

13 Nov '97

Greetings, We operate an anonymous FTP service using the wuarchive FTP daemon (wu-2.4.2-academ[BETA-13]) on an Alpha running Digital Unix 4.0b. The files are stored on a filer running 4.0.1c. >From time to time we set up anonymous FTP groups, so remote anonymous users can supply a group password to gain special access to normally inaccessible areas. When the FTP data area was on a local file system on an OSF/1 3.2 system, people could use this group access to upload files onto the FTP server. Now that we have upgraded the OS and moved the data to a filer, attempts to do this result in the error 550 fchown: Not owner. and a 0-length file on the filer. Can anybody shed light on why this might be happening? Thanks, Mic Kaczmarczik Unix Services UT Austin Academic Computing -- Mic Kaczmarczik -- Unix Services -- UT Austin Academic Computing (ACITS) --

1 0

Re: NetApp burn-in testing (was "raid swap question")
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

Another test, that has been talked about by Netapp before but which Dave didn't mention, is in-house production testing. Almost every new software release, hardware model, and new feature (like ATM) gets time in production use in Netapp's own "Real World" corporate network, often within Engineering itself. While not specifically a QA function, Netapp does integrate it's own products into their infrastructure as best as possible and such rollouts have proven to be very fruitful at identifying problems and correcting them before they reach the customers. Bruce

1 0

Re: backing up large filers
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

>As for stackers directly attached to the filers, what have folks found >that works? When we first tried this (long ago with an ADIC DLT 2500xt >"stacker"), we found that the stacker mechanism was quite lousy and tended >to hang. Thus we had to reboot the filer to "un-hang" the stacker. I >have stayed away from diretly connected drives since. I used directly attached DLT-4700s at Netapp and never had one with a hung stacker mechanism. If the UNIX host firing off the dump over rsh died, it *could* leave the dump/drive hung and thus requiring a reboot of the filer to fix, but that was rare. Bruce

1 0

Re: raid swap question
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

On 11/04/97 07:02:23 you wrote: > We have a bunch of filers sitting idle waiting for some >back-ordered components, so I've taken the opportunity to "stress" >them and see what breaks. ;-) On a quiet filer (no exports), I >started with a two-disk configuration (it doesn't seem to mind having >only one parity and one data disk) and hot-plugged four more drives in >rapid succession without a `raid swap'. > > The usual warnings on the first write to a new disk were logged, >but then the filer complained about all three SCSI buses (only 9a was >in use at the time). Beyond that there were no other difficulties. Of course, you may have just been lucky. Under different circumstances or configurations it could very easily hang or crash your filer. Don't try this at home, folks (well, at least not until it's supported). You'll note that it had to reset the adapater and the bus to try and regain a sense of sanity. Bruce

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