toasters March 1998

toasters@lists.teaparty.net

48 participants
57 discussions

Re: Data ONTAP 5.0 memory requirements
by Jason D. Kelleher 17 Apr '98

17 Apr '98

In message <Chameleon.980326065754.dpower(a)blue.insync.net>, David Power writ es: >Have you priced 630 memory lately? I was quoted $12,000 for a 32 meg >nvram, 256 meg system ram upgrade. Thats not dropping to me. We just paid NetApp $4000 to up the NVRAM on our F330 from 2MB to 8MB. That's over $650 for each 1MB SIMM! When I asked our Sales Rep about the cost, I was quoted the "We do in house testing" line. Anyway, two of the SIMMs we were sent were bad... Very disappointing. I think it'd work out best for everyone if they just published a list of "approved" vendors for memory and disk. The customers would get a better price, and NetApp would look alot nicer. jason >--- On Thu, 26 Mar 1998 17:30:52 +1100 Mike Bosch <mbosch(a)netapp.com> >wrote: > >>Marc, >> >>As I recall, Cisco was requiring 64MB and recommending 128MB on most ISP >>7500s over a year ago. Whatever......the point is that memory >requirements >>will continue to grow over time. >> >>The good news is that as more features have required more memory, the >price >>of memory has dropped at an even faster rate. >> >>MJB >> >> >>At 22:21 25/03/98 -0500, Marc Nicholas wrote: >>>On Thu, 26 Mar 1998, Mike Bosch wrote: >>> >>>> A Filer is generically much more like a router than a general purpose >Unix >>>> or NT box, but we still require much less space than Cisco's IOS, for >>example. >>> >>>Excuse me? You require less memory than IOS? Did I suddently reappear >in >>>another universe where IOS requires 128mb to run? :-p >>> >>>You can even run a couple of full BGP views in a Cisco with 64mb -- and >>>that's to compensate for Cisco's braindead table archietecture. >>> >>> >>>-marc >>> >>>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>Hippocampus OSD, Inc. "Industrial Strength Internet Solutions" >>>vox://416.979.9000 fax://416.979.8223 http://www.hippocampus.net >>> >>> >>> >> >> >>-------------------------------------------------------------------------- >-- >>------ >> >>Mike Bosch >>Regional Manager >>Network Appliance Australia - New Zealand >> >>Phone: 61-41-728-7345 >>Email: mbosch(a)netapp.com >> >> >>********************************************************************* >> FAST SIMPLE RELIABLE MULTI-PROTOCOL >>********************************************************************* >> >> >>-------------------------------------------------------------------------- >-- >>------ >> >> > >-----------------End of Original Message----------------- > > >David Power >V-P Operations >Insync Internet Services Inc. > >

9 9

Re: 4GB/9GB shelf migration from toaster A to toaster B.
by Daniel Quinlan 31 Mar '98

31 Mar '98

Daniel Quinlan wrote: >> You can get back your 4GB spare, since you only need one spare. The >> spare only has to be the same size of the largest data disk in the >> system. If you have a 9GB spare and a 4GB disk fails, you end up >> adding 5 GB to the filesystem when the spare replaces the failed >> disk. kls(a)netapp.com (Karl Swartz) writes: > No, you end up putting 4GB on a 9GB drive and getting no more space in > the file system than you had before. (If there are multiple spares in > the system, the smallest one which is large enough to replace the > failed drive will be used.) That's a shame. Is this information documented somewhere? - Dan

2 1

Re: 4GB/9GB shelf migration from toaster A to toaster B.
by Daniel Quinlan 31 Mar '98

31 Mar '98

Jim Davis <jdavis(a)CS.Arizona.EDU> writes: > Potential plan: buy a shelf of 9GB disks, put it on toaster A, move a > shelf of 4GB disks to toaster B, keeping all of the toaster A data on > toaster A. Toaster B ends up with an empty file system on its 4GB disk > shelf. > > Now the mechanics of the move are a little unclear to me. Presumably we > hook up the 9GB shelf to toaster A and 'raid fail' each 4GB disk in the > shelf we want to move? But there will be 5 9GB data disks, since we have > to burn one as a hot spare and one becomes the new parity disk. Will > there be a problem with having 7 disks to move data from, but only 5 disks > to move data to? There would be enough GBs on the 5 9GB disks, but... Yes, it won't work as you suspect (unless, of course, you do a backup-restore cycle) because the total number of disks in a NetApp RAID group can't be reduced, even if the capacity is increased. You can get back your 4GB spare, since you only need one spare. The spare only has to be the same size of the largest data disk in the system. If you have a 9GB spare and a 4GB disk fails, you end up adding 5 GB to the filesystem when the spare replaces the failed disk. Dan

4 3

Netapp Announces F630 Cluster
by sirbruce＠ix.netcom.com 31 Mar '98

31 Mar '98

So, who wants to get one of the new F630 clusters, aka the F6300? The announcement was out today. Has anyone here had any experience with Tandem's ServerNet technology and can comment on it's strengths and weaknesses? And on a side note, how about that stock price. :) Bruce

4 3

Re: shares
by Keith Brown 28 Mar '98

28 Mar '98

>what the largest number of any shares anyone's currently exporting from a >toaster? In ONTAP releases prior to 4.3, we had an upper limit that amounted to about a thousand shares in a typical configuration. The actual limit was "fuzzy", because it wasn't defined by any hard, static configuration that directly limited the number of shares to a certain specific number. It was defined by an internal buffer pool and some semantics that were specific to the algorithms that managed the use of those buffers when Windows clients attempted to enumerate a filers shares. To give you an idea of what I mean, you could actually create quite a few more than 1000 shares using these older versions of ONTAP, as long as you kept the comments you placed on those shares to a minimum (making them either short or non-existent). The up-to-32-character share comments that Windows allows you to associate with shares used up space in these buffers that would otherwise have been usable to define more shares in! :-) However, as of ONTAP 4.3.3 and beyond, this way of doing things ceased to exist. The upper limit on the number of shares a filer can export is currently a function of the amount of memory you have installed. On the F5XX and F6XX filers, you're looking at a limit of: 2400 + 2000*(# of 64MB chunks above 128MB) and on the F2XX and F3XX the numbers are ironically even higher due to a difference in the size of memory addresses used by the CPU's we use in the lower end filers versus the CPU's we embed in the higher end filers. Bottom line, we're talking about a veritable truckload of shares here. When the limit used to be around a thousand, I only knew of two customers who "discovered" it. Oh... I should probably mention that these limits are not inclusive of the automatic shares that are generated on the fly for individual users when you set the: options cifs.home_dir /wherever/whatever option. In other words, these *don't* count towards the total, and these could potentially amount to thousands more shares than just the statically defined ones. > are there performance penalties associated with too many shares, No, unless you count the amount of time it takes to enumerate the things (that's the amount of time you have to stare at the torch (flashlight) scanning backwards and forwards after you have double clicked the filer under "Network Neighborhood"). However, whatever amount you've created, I think it's a pretty safe bet that Data ONTAP will spit 'em back at you more rapidly than NT would given the same number. ONTAP has a rather tight focus on the such matters. :-) Keith

1 0

Anyone using DEC TZ88 DLT drive with their NetApp?
by Bill Bradford 27 Mar '98

27 Mar '98

Anybody out there using a DEC TZ88 (DLT 4000) drive with their Netapp? I asked support about it being a supported drive (its basically hardware identical to a Quantum DLT4000, just returns a different ID string) and they said "you'll have to change the string it returns to match another DLT drive, sorry." I'd *really* like to get this to work without modifying it. Bill -- Bill Bradford Systems Engineer, Texas.Net http://www.texas.net mrbill(a)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?"

1 0

Re: first experience with RAID groups
by Daniel Quinlan 27 Mar '98

27 Mar '98

Timothy A. McCarthy <tmac(a)netapp.com> writes: > If you want a "neat" looking raid group, you can use the vol command: > vol add volname ndisks -d diskname > volname=volume name > ndisks=num of disks to add > diskname= a space separated list of drives that you want to use > > vol add vol0 10 -d 8b.0 8b.1 8b.2 8b.3 8b.4 8b.5 8b.8 8b.9 8b.10 8b.11 I think that's the wrong syntax to specify a list of disks to add. Everything after the "10" is ignored. This is actually the same exact mistake I made, illustrating how confusing the vol documentation is. What I tried was: vol add vol0 2 -d 8b.0 8b.1 And the system proceeded to add 8b.13 and 8b.14. I think this is the right syntax: vol add vol0 -d 8b.0 8b.1 8b.2 8b.3 8b.4 8b.5 8b.8 8b.9 8b.10 8b.11 I would guess that even with the above syntax for specifying a list of disks to be added, disks are still added in a random order. - Dan

1 0

first experience with RAID groups
by Daniel Quinlan 27 Mar '98

27 Mar '98

Some first-try comments on RAID groups: the order in which disks get added to new RAID groups is pretty screwy. Group 0 was the original v4.1 group and I just created group 1. Group 0 is pretty straightforward. Group 1 is not. It would be nice if one of the following was implemented: - there was also some sort of "fake" command that would show you what would be done if you tried a certain command. Since this was my first experience with setting the volume raidsize, I wasn't 100% certain where the next disk I added. - a way to abort disk additions while they are still being added Basically, since disk changes are non-reversible, there should be some comfort/safety margin for configuring things the way you want them to be configured. Other than that, it wasn't too bad, although I'm starting to find the "vol" command really awkward to use. Dan ------- start of cut text -------------- thorium> sysconfig -r Volume vol0 RAID group 0 RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- parity 8a.1 8600/17612800 8683/17783112 data 8a.2 8600/17612800 8683/17783112 data 8a.3 8600/17612800 8683/17783112 data 8a.4 8600/17612800 8683/17783112 data 8a.5 8600/17612800 8683/17783112 data 8a.8 8600/17612800 8683/17783112 data 8a.9 8600/17612800 8683/17783112 data 8a.10 8600/17612800 8683/17783112 data 8a.11 8600/17612800 8683/17783112 data 8a.12 8600/17612800 8683/17783112 data 8a.13 8600/17612800 8683/17783112 data 8a.14 8600/17612800 8683/17783112 RAID group 1 RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- parity 8b.14 8600/17612800 8683/17783112 data 8b.13 8600/17612800 8683/17783112 data 8b.12 8600/17612800 8683/17783112 data 8b.4 8600/17612800 8683/17783112 data 8b.8 8600/17612800 8683/17783112 data 8b.3 8600/17612800 8683/17783112 data 8b.5 8600/17612800 8683/17783112 data 8b.9 8600/17612800 8683/17783112 data 8b.1 8600/17612800 8683/17783112 data 8b.11 8600/17612800 8683/17783112 data 8b.10 8600/17612800 8683/17783112 data 8b.2 8600/17612800 8683/17783112 ------- end ----------------------------

2 1

Re: Data ONTAP 5.0 memory requirements
by sirbruce＠ix.netcom.com 27 Mar '98

27 Mar '98

On 03/27/98 17:13:43 you wrote: > > >> I received a notice for voluntary recall on those Storageshelf-2 >> EMU units from Netapp... haven't had any problems with ours yet, >> thankfully. > >Our EMU keeps complaining about a fault on the SS-2, which I'm told is >because it's a bit too fussy... I hadn't heard about any recall, what's >the story? This can also happen if your filer is not cabled exactly as specified. You should double-check the cabeling. (It could also be an EMU problem, in which case you should get it fixed.) I don't know about the recall myself but if you have a cabling problem it's doubtful new EMUs would fix it. Bruce

1 0

Re: Data ONTAP 5.0 memory requirements
by David Power 27 Mar '98

27 Mar '98

Have you priced 630 memory lately? I was quoted $12,000 for a 32 meg nvram, 256 meg system ram upgrade. Thats not dropping to me. --- On Thu, 26 Mar 1998 17:30:52 +1100 Mike Bosch <mbosch(a)netapp.com> wrote: >Marc, > >As I recall, Cisco was requiring 64MB and recommending 128MB on most ISP >7500s over a year ago. Whatever......the point is that memory requirements >will continue to grow over time. > >The good news is that as more features have required more memory, the price >of memory has dropped at an even faster rate. > >MJB > > >At 22:21 25/03/98 -0500, Marc Nicholas wrote: >>On Thu, 26 Mar 1998, Mike Bosch wrote: >> >>> A Filer is generically much more like a router than a general purpose Unix >>> or NT box, but we still require much less space than Cisco's IOS, for >example. >> >>Excuse me? You require less memory than IOS? Did I suddently reappear in >>another universe where IOS requires 128mb to run? :-p >> >>You can even run a couple of full BGP views in a Cisco with 64mb -- and >>that's to compensate for Cisco's braindead table archietecture. >> >> >>-marc >> >>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>Hippocampus OSD, Inc. "Industrial Strength Internet Solutions" >>vox://416.979.9000 fax://416.979.8223 http://www.hippocampus.net >> >> >> > > >---------------------------------------------------------------------------- >------ > >Mike Bosch >Regional Manager >Network Appliance Australia - New Zealand > >Phone: 61-41-728-7345 >Email: mbosch(a)netapp.com > > >********************************************************************* > FAST SIMPLE RELIABLE MULTI-PROTOCOL >********************************************************************* > > >---------------------------------------------------------------------------- >------ > > -----------------End of Original Message----------------- David Power V-P Operations Insync Internet Services Inc.

5 4

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 March 1998