toasters

toasters@lists.teaparty.net

13531 discussions

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

shares
by Tom Yates 27 Mar '98

27 Mar '98

what the largest number of any shares anyone's currently exporting from a toaster? are there performance penalties associated with too many shares, and at what point does that start? Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

1 0

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

27 Mar '98

I tried that, kingston went "netapp 630, duhhh". That was totaly unexpected from them. I've always had great support from them before. --- On Thu, 26 Mar 1998 17:04:48 -0800 (PST) Jaye Mathisen <mrcpu(a)cdsnet.net> wrote: > >Call Kingston, they had the NVRAM and RAM that Netapp used as I recall, >and it plugs in and works fine, and you don't have to get taken to the >cleaners. > >On Thu, 26 Mar 1998, David Power wrote: > >> 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. >> >> >> > -----------------End of Original Message----------------- David Power V-P Operations Insync Internet Services Inc.

3 2

Re: Data ONTAP 5.0 memory requirements
by Lewis Kirschner 27 Mar '98

27 Mar '98

Wrong!! Read-Cache and NVRAM different for F540 vs F630!! Yes... its true!!! Be careful !! ----- At 07:47 PM 3/26/1998 -0800, Jaye Mathisen wrote: > >Well, I would suspect it's the same as the 540 memory, which they list. > >Sometimes you have to try a few times, they have various quality levels >of sales people. > >The first time I wanted 540 memory, I found it on the web page, and >was reading her the part number and she was telling me it didn't exist. > >Called back, spoke to a different person, and no problem. > >On Thu, 26 Mar 1998, David Power wrote: > >> I tried that, kingston went "netapp 630, duhhh". That was totaly >> unexpected from them. I've always had great support from them before. >> >> >> --- On Thu, 26 Mar 1998 17:04:48 -0800 (PST) Jaye Mathisen >> <mrcpu(a)cdsnet.net> wrote: >> >> > >> >Call Kingston, they had the NVRAM and RAM that Netapp used as I recall, >> >and it plugs in and works fine, and you don't have to get taken to the >> >cleaners. >> > >> >On Thu, 26 Mar 1998, David Power wrote: >> > >> >> 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. >> >> >> >> >> >> >> > >> >> -----------------End of Original Message----------------- >> >> >> David Power >> V-P Operations >> Insync Internet Services Inc. >> >> >> > > > NETWORK APPLIANCE ====================================================================== FAST! SIMPLE! RELIABLE! MULTIPROTOCOL!! ********************************************************************** Lew Kirschner - Eastern Area Reseller Mgr Voice: 908 603 7330 Network Appliance FAX: 908 603 7795 120 Wood Ave Suite 300 email: lewisk(a)netapp.com Iselin, NJ 08830 http://www.netapp.com ********************************************************************** The Market Leader in Network Attached Storage for Multiprotocol Environments!

1 0

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

27 Mar '98

On 03/26/98 13:45:12 you wrote: >>Exactly how were they "bad"? Did they not work when you added them, or >>did they work but you had to troubleshoot crashes that caused you to swap >>them out, etc.? Netapp does indeed do testing that catches bad SIMMs from >>the vendor, but it can't catch problems where the SIMM is damaged after >>testing in handling, or in shipping, or improperly inserted into the board. > > Failed to boot w/ the error, "Unsupported NVRAM size 5MB", after >placing the six new SIMMs in the NVRAM card. Did the memory shuffle >(got very annoyed because it doesn't report this error until close to >the end of the boot process) and narrowed the problem down to 2 SIMMs. >Then I proceeded to get really pissed (only allowed to do non-emergency >hardware maintenance on the filer Friday's after 19:30) because I spent >over an hour and ruined a Friday night to add 2MB of NVRAM. (F330's >support 2, 4, or 8 MB - not 6.) When I've seen this in the past, it's been due to improper insertion of the SIMMs into the board. But it could be the SIMMs were bad or even the slots on the board were bad. I assume you've gotten new SIMMs since then and they worked fine? >>Sometimes the time at which a SIMM will fail in the future is beyond their >>horizon of testing. It seems to me getting it straight from the vendor is > > How were these tested? I can only speak in general terms. To say they're just put in a memory tester would be incorrect; they get burned (or at least, they used to) just like the DRAM. >My filer didn't even acknowledge their >exictence. Granted, they could have been damaged during shipping... >Or, I could have zapped them when I opened the packaging while grounded >to our ESD bench... Maybe I don't know how to install SIMMs and just >always got lucky before... (Please excuse the sarcasm.) No need to be sarcastic. All of those are very possible, no offense intended to your consider memory installation skill. :) But surely they were tested at Netapp, so it seems like you can't "blame" them for a failure later. Is the chance of a failure later still large enough that Netapp's testing isn't worth it? Again, that's an individual choice. >>only going to increase your chances of failure, unless maybe there is a >>particular vendor with which Netapp has rarely encountered failures. > > I disagree. I'd prefer to go to a vendor with which _I_ have >rarely encountered failures. Well, that is mostly wordplay. Surely one person's experience is not as predictive as testing thousands of such SIMMs, but most people do develop such individual biases, especially if they get a couple of failures in a certain vendor in a row. The point of the sentence was simply that NVRAMs are tested and they do fail, so if you want to go with a vendor that isn't tested, it would seem your best choice would be one that historically had failed little in said testing. >>Does it justify increased price? Hard to say. Depends upon the atmosphere >>of the company/environment your in. If it's like many bosses I know, the >>increased price isn't worth it until a component fails, and then they get >>upset that you didn't get better quality. :) > > Increased price isn't a problem if you _do_ get better quality. We >paid a 600% mark up on parts that had to be shipped back and replaced >as soon as we tried to use them. That doesn't mean you don't get better quality. Without Netapp's testing, it's more probably that you would have gotten bad parts twice in a row. If you have multiple filers, you would generally see more bad SIMMs, etc. > I'm not saying NetApp is low quality. We've seen great uptime w/ >our F330 and keep asking for details on their HA system because we >think NetApp is a good bet. I just don't like the way they handle >memory and disk sales. This is more or less what I was getting at, too. Netapp does do quality testing, and I think that's better than no testing. Is it worth, assuming your figures, a 600% mark up? It seems many people on mailing list say it isn't. What about a 200% mark up? Bruce

1 0

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

26 Mar '98

On 03/26/98 10:52:18 you wrote: > >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. Exactly how were they "bad"? Did they not work when you added them, or did they work but you had to troubleshoot crashes that caused you to swap them out, etc.? Netapp does indeed do testing that catches bad SIMMs from the vendor, but it can't catch problems where the SIMM is damaged after testing in handling, or in shipping, or improperly inserted into the board. Sometimes the time at which a SIMM will fail in the future is beyond their horizon of testing. It seems to me getting it straight from the vendor is only going to increase your chances of failure, unless maybe there is a particular vendor with which Netapp has rarely encountered failures. Does it justify increased price? Hard to say. Depends upon the atmosphere of the company/environment your in. If it's like many bosses I know, the increased price isn't worth it until a component fails, and then they get upset that you didn't get better quality. :) Bruce

2 1

Re: Data ONTAP 5.0 memory requirements
by Mike Bosch 26 Mar '98

26 Mar '98

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 ********************************************************************* ---------------------------------------------------------------------------- ------

1 0

Data ONTAP 5.0 memory requirements
by Brian Tao 26 Mar '98

26 Mar '98

[http://now.netapp.com/download/software/ontap/5.0/] > Software Download Instructions > > Important: Data ONTAP 5.0 requires 128MB of memory on the filer to run > properly. If you do not currently have 128MB of memory, contact our > Installed Base Group either by e-mail or by phone at 1-888-2NETAPP. Ouch. 128MB? Why is that? Will filers be sold with a minimum configuration of 128MB in the future? -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

10 9

new quota tools: netapp-qdiff and netapp-qformat
by Daniel Quinlan 25 Mar '98

25 Mar '98

I cleaned up two more small scripts of mine sufficiently that I don't mind showing them to other people. The first is "netapp-qdiff", which essentially subtracts one quota report from another, and shows you what changed between the two. It only works on NetApp 5.0 right now, but if 4.x capability is wanted, I'll consider trying to add it. The second is "netapp-qformat", which prints out the quota report in a format that my small brain can read. It lines things up, converts to MB, prints decimal fractions for small usages, and sorts by tree name and disk usage. It should work for both NetApp 4.x and 5.0. The two scripts can work together, so here's what the output of a netapp-qdiff piped through netapp-qformat might look like. It's a little wide, just like the 5.0 quota report format: M-Bytes Files Type ID Volume Tree Used Limit Used Limit Quota Specifier ----- -------- -------- -------- ------- ------- -------- -------- ----------------- tree 1 vol0 local 0 0 2 - /local tree 2 vol0 transmeta-ht 10 0 57 - /transmeta-htdocs user joe vol0 transmeta-ht 8 0 10 - user bob vol0 transmeta-ht 2 0 47 - user mary vol0 transmeta-ht 0.1 0 4 - user jill vol0 transmeta-ht 0.1 0 3 - user billy vol0 transmeta-ht 0 0 -1 - user pat vol0 transmeta-ht 0 0 -2 - Also, instead of continuing to post my scripts here, I stuck the last three at <URL:http://www.pathname.com/~quinlan/netapp/>. So, is anyone finding this stuff useful or does everyone here administer their filers from Windows? - Dan

1 0

Re: splitting the load
by Daniel Quinlan 23 Mar '98

23 Mar '98

Tom Yates <madlists(a)mathworks.com> writes: > i'm planning to migrate about one-third of an existing F330's filespace > to another F330. what i want to do is move the most frequently accessed > third, so it has its own dedicated toaster. > > there are currently three file trees, each separately listed in exports, > each with its own CIFS share. is there any kind of monitoring tool i can > use to give me some idea of which of these three is the most heavily used? There is a program called nfswatch (a network snooper), but it only handles NFSv2 and may not have the information you want. If the traffic to each of the three file trees is used more by certain hosts, another method is to use the per-client statistics to make an educated guess. You could also monitor the turnover on each tree's filesystem - atime changes, mtime changes, etc. - Dan

1 0

Re: NetApp Support
by sirbruce＠ix.netcom.com 23 Mar '98

23 Mar '98

On 03/23/98 10:28:58 you wrote: >When I've got a bug that's affecting my customers and the quality of >service I'm offering, I could care less if its been "sanitized" and >internal engineering comments / cuss words / etc has been removed - I >want the *info available*, or at least indication that the problem >*is* an acknowledged bug and NetApp is working on it, as *soon as >possible*. Not to be an apologist for Netapp, but I have seen other reasons offered from time to time. For example, internal bug reports can contain portions of source code or other proprietary facts about the internal workings of the filer, bugs that are mischaracterized (which could mislead the unsuspecting customer into thinking it is something else), or even disagreements between engineers over the nature of the bug involved. I think these sorts of things should be filtered. Furthermore, some bugs get discovered in internal testing that do not get immediately fixed at release. Someone would have to, at release, identify these bugs that still exist and move them into the "public", as it were. >NetApp, if you're going to keep a list of bugs on your web page, make >sure they're up-to-date, otherwise such info is useless. >I've made this request at least twice, and never heard anything of it. I agree. I'm sure Netapp agrees as well. Putting the manpower and expertise together to do that, however, is not as easy as it may seem on a first pass. >The other "minor annoying" problem I've seen with the Toasters: > >nfs> exit >Use control-D to exit >nfs> ^D >Connection closed by foreign host. > >Why not just use the code that is in the OS to print "Use control-D to exit" >to make the filer go ahead and exit? I got an answer to this when I first asked it during the 1.x days. :) You may have noticed by now that the filer doesn't really support multiple tty sessions. If you're on the console and someone else telnets in, you're really multiplexed off the same character stream. So when the command parser gets an "exit", it doesn't know which connection(s) it came from. The control-D, on the other hand, is caught higher up in the input driver. I suppose one could check to see if there is only one session. Or there may be a way to put together some code to determine where the command came from. But the real fix would be to support multiple concurrent sessions. With the emphasis on GUI and rsh and such in more recent releases, that feature may not even be on the roadmap anymore. Or, maybe it's in 5.x? Bruce

2 1

splitting the load
by Tom Yates 23 Mar '98

23 Mar '98

i'm planning to migrate about one-third of an existing F330's filespace to another F330. what i want to do is move the most frequently accessed third, so it has its own dedicated toaster. there are currently three file trees, each separately listed in exports, each with its own CIFS share. is there any kind of monitoring tool i can use to give me some idea of which of these three is the most heavily used? Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

1 0

Re: NIS Binding Problem
by Jason D. Kelleher 23 Mar '98

23 Mar '98

In message <35119FA5.91C737AD(a)lucent.com>, Dave Heiland writes: >This annoys me since I reported last year when I first set up my Netapp tha >t NIS >wasn't working right. Performance was awful, and it was rebinding to a >different NIS slave every couple of seconds. I never heard much back, and >because I immediately switched to using local netgroups I didn't have the >problem again. At least there will finally be a fix. > >Dave I wouldn't get your hopes up. I was sent that message over 5 months ago... jason >> When we first turned on NIS, everything went to hell. The filer >> started denying mounts to all the clients. Unfortunately, it didn't do >> this right away, took several hours. Seems the filer wasn't getting >> netgroup info. Anyway, here's what NetApp told me: >> >> > Hi Jason, >> > >> > I had one of our escalation engineers look over this >> > call with me. >> > >> > We believe that what you saw when upgrading to 4.1d >> > is the result of an inefficient method we use to >> > "lookup" the YP information. Instead of doing 3 or 4 >> > lookups to get the netgroup info when the mount is >> > checked we would do one for *every* line in the netgroup >> > file. >> > >> > This behavior has been logged as bug#4088 in our database >> > and engineering is working to modify the NIS client to >> > correct this problem. >> > >> > For now the recommendation would be to continue using >> > the local file method which hasn't caused you any >> > problems. When a fix is available for #4088 then you >> > could upgrade and begin using the NIS client for >> > netgroup which should be much faster. One of the >> > benefits of NIS client is that these lookups should >> > be faster but with our first release of this NIS >> > client they simply are not. >> > >> > I have flagged this call record as bug#4088 with all >> > the info you sent to me. The escalation engineer I >> > spoke with is actually the one that will fix the NIS >> > code and by flagging your call record as this bug >> > he can review it during the time he makes the patch. >> > >> > This would first be available as a patch release >> > (a release with a capital D in it such as you >> > were running prior to upgrading to 4.1d). The >> > best way to find out when it is available would be >> > to call back and reference the bug#4088 and ask >> > if Eirik has a patch for the NIS client yet. I >> > would think that you might want to wait 30 days or >> > so -- there is no schedule for a fix date for this >> > right now. >> > >> > Regards, >> > Gil >> >> I never bothered to check back. NOW lists bug #4088 as unfixed. >> Here's our nsswitch.conf which "solved" our problems: >> >> # >> # nfssrv1:/etc/nsswitch.conf >> # >> >> passwd: files nis >> group: files nis >> >> hosts: files nis dns >> netgroup: files nis >> >> Good Luck. >> >> --- >> Jason D. Kelleher kelleher(a)susq.com >> Susquehanna Investment Group 610.617.2721 (voice) >> 401 City Line Ave, Suite 220 610.617.2916 (fax) >> Bala Cynwyd, PA 19004-1122

7 10

Re: netapp-top - display current top NFS clients for a NetApp
by sirbruce＠ix.netcom.com 23 Mar '98

23 Mar '98

On 03/23/98 09:36:38 you wrote: > >Nice little script. Now, the question is, what sort of performance hit will >I take if I turn on nfs.per_client_stats.enable ? I am assuming that on a >moderately loaded f630 it shouldn't be much of a problem. Very little. I know it was measured at one point but it was nothing very important. Probably less than the impact of quotas. And more than worth the tradeoff. For an F630 I doubt it would even register a 1% difference. Bruce

1 0

Re: NetApp Support
by Andrew Hobson 23 Mar '98

23 Mar '98

On Mon, 23 Mar 1998 09:23:00 -0500, Gerard Hickey <Gerard.Hickey(a)nsc.com> said: > Does anyone else out there have problems with NetApp support? Or is it > just me? We've had some serious support issues as well which we vented in a conference call with NetApp. They acknowledged problems and are working to come up with solutions. We'll see. :-) Drew -- "I must obey the inscrutable exhortations of my soul. My mandate also includes weird bugs." -- Calvin

1 0

netapp-top - display current top NFS clients for a NetApp
by Daniel Quinlan 23 Mar '98

23 Mar '98

Here's a useful little script, especially if you ever need to determine which hosts are banging the hardest on an overloaded NetApp. Example output: NFS/s total NFS/s = 2217 | interval = 60 ------ ---------------------------------------- 439 sodium.transmeta.com 437 iridium.transmeta.com 264 tee.transmeta.com 102 manganese.transmeta.com 49 hammer.transmeta.com 43 iron.transmeta.com 41 blighty.transmeta.com 39 curie.transmeta.com ... Before writing this, I usually ended up zeroing the per-client stats or using "diff" between two "nfsstat -l" commands to determine the current top NFS clients. If you make any significant improvements, please send them back to me. Also, please do not post this to Usenet or on a public web site with my email address (spam paranoia). Thanks. - Dan ------- start of cut text -------------- #!/usr/local/bin/perl # netapp-top - display current top NFS clients for a NetApp # Copyright (C) 1998 Daniel Quinlan # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. $default_interval = 60; $prog = $0; $prog =~ s@.*/@@; require "getopts.pl"; &Getopts("hi:"); if (defined $ENV{"LINES"} && $ENV{"LINES"} ne "") { $lines = $ENV{"LINES"}; } else { $lines = 24; } if ($opt_h) { &usage; exit 0; } if ($opt_i && $opt_i > 0) { $interval = $opt_i; } else { $interval = $default_interval; } if ($ARGV[0]) { $host = $ARGV[0]; } else { &usage; exit 1; } sub usage { print <<EOF; usage: $prog [options] filer -h print this help -i n report filer statistics every n seconds ($default_interval is default) The NetApp must have the "nfs.per_client_stats.enable" option "on" for this to work at all. This program must be run this from an admin host as root. EOF } sub print_top { my $total = 0; my $diff; my %recent; foreach $key (keys %nfs_ops_last) { $diff = $nfs_ops{$key} - $nfs_ops_last{$key}; $recent{$key} = $diff; $total += $diff; } $total = int ($total / $interval); system("clear"); printf "%6s\t%s\n", "NFS/s", "total NFS/s = $total | interval = $interval"; printf "%6s\t%s\n", "------", "----------------------------------------"; $i = 0; foreach $key (sort {$recent{$b} <=> $recent{$a} } keys %recent) { printf "%6d\t%s\n", int ($recent{$key} / $interval + 0.5), $ip_name{$key}; last if ($i++ > ($lines - 5)); } } $first = 1; for (;;) { $time_0 = time(); open(NFSSTAT, "rsh $host nfsstat -l|"); while (<NFSSTAT>) { @tmp = split; # ip_address = tmp[0] # ip_name = tmp[1] # nfs_ops = tmp[4] $ip_name{$tmp[0]} = $tmp[1]; $nfs_ops{$tmp[0]} = $tmp[4]; } close(NFSSTAT); if (! $first) { &print_top; } else { $first = 0; } %nfs_ops_last = %nfs_ops; $time_1 = time(); sleep ($interval - ($time_1 - $time_0)); } ------- end ----------------------------

2 1

inn and 630
by David Power 21 Mar '98

21 Mar '98

Has anybody had any success using a 630 as a back end for inn? We are experiencing some horrible thruput issues with large files. The Inn machine is a multi processor sparc 20s w 512 meg ram running 2.6. Nettapp is a 630 8meg nvram 256meg system ram 100bt full duplex connection between the sparc and the netapp. System load is around 10% Systat 1 shows writes are flushed at around 10 sec intervels, cache age is sitting between 11 and 20. To quote my sys admin. "When INN writes an article, it opens it (O_WRONLY|O_CREAT|O_TRUNC), fills the buffer, then writev's to write out the buffer. This works great on small files, but large files are making the writev just hang for a second or so (not coincidentally at the same time that the dnewslink process sleeps in diablo). I tried changing the open to O_WRONLY|O_NONBLOCK|O_CREAT|O_TRUNC, but apparently non-blocking writes don't happen over NFS. Anyway, the key to solving this is getting the Netapps to write big files faster. Any ideas?" David Power V-P Operations Insync Internet Services Inc.

3 2

None
by Mark D Simmons 20 Mar '98

20 Mar '98

Sorry, didn't cc this properly: --- Forwarded mail from "Mark D Simmons" <mds(a)gbnet.net> >From mds(a)gbnet.net Fri Mar 20 22:02:23 1998 Return-Path: <mds(a)gbnet.net> Delivered-To: mds(a)gbnet.net Received: (qmail 7924 invoked by uid 130); 20 Mar 1998 22:02:23 -0000 Date: 20 Mar 1998 22:02:23 -0000 Message-ID: <19980320220223.7922.qmail(a)ns.gbnet.net> From: "Mark D Simmons" <mds(a)gbnet.net> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: tonylai <tonylai(a)ms7.mitac.com.tw> Subject: Re: Disk drives prices Cc: mds(a)gbnet.net Because the NetApp complexity and cost is actually superior to all the vendors I mention as my fall-back choices. For many specific tasks, including other file and database servers, we do in fact use Sun and SGI. NetApp boxes provide vast, easily managed pools of disk that I rarely need to intervene with to keep running so their cost- effectiveness wrt my time is very high. Ditto the availability of the data we keep on them. --- End of forwarded message from "Mark D Simmons" <mds(a)gbnet.net>

1 0

RE: ontap 5.0?
by Cheryl Herfurth 20 Mar '98

20 Mar '98

Hi Dave, I'm very interested in your comments about the 5.0 readme file. We will put it in .html format; that's the easy part. What I'm really interested in is what kind of information you thought was worthless, and more importantly, what kind of information you were looking for. For the 4.3 release, the Read Me First was much longer (some 40 pages) and covered a lot more material. We received several comments that it was too long, and that the Read Me First should be very short and only point to where other information resides. We're in the process of re-designing the entire documentation set and are very interested in customers' expectations about what information goes where. If you have any feedback on this wider issue, please let me know. Thank you for your interest in helping us improve the documentation. If I can be of any further assisntance, please don't hesitate to contact me. Cheryl Herfurth Tech Pubs Manager Network Appliance phone: (408) 367-3522 fax: (408) 367-3451 -----Original Message----- From: Dave Cole [SMTP:dacole@netcom.ca] Sent: Wednesday, March 18, 1998 7:52 AM To: toasters(a)mathworks.com Subject: ontap 5.0? Well, I heard it is out. I went to the now.netapp.com site. I see the announcement, I go to the software library. ONTAP 3.1.6 is the latest recommended release? What happened to 4.3.1? I think something is broken. Either that, or NetApp is celebrating April 1st a little early. I noticed in the 5.0 announcement that they say the Exabyte Mammoth is only supported on the F630. Why would such a limitation be made? And while I'm here, I might mention that the PDF file format is quite possibly the second most annoying thing found on the internet, surpassed only by spam. I blew off far too much time trying to get a reader for the 5.0 readme file, only to find 1.25 pages of almost-completely-useless text. ------------------------------------------------------------- Dave Cole (DC1110) | dacole(a)netcom.ca Systems Administrator | dacole(a)vex.net | office/~dacole/ Netcom Canada | www.vex.net/~dacole/ 905 King Street West, Toronto, M6K 3G9 | phone - 416.341.5801 Toronto, Ontario, Canada, Earth, Sol | fax - 416.341.5725

1 0

Re: NIS Binding Problem
by Paul Albers 20 Mar '98

20 Mar '98

Hello Tony, There currently is a "D" patch release with the fix for bug #4088 and bug #5086. This patch is available at http://now.netapp.com/ 4.3.1D7 is the release. If you have any questions, please call our Tech Support at 888.463.8277. Regards, -paul At 09:23 AM 3/20/98 +0800, you wrote: >Dave, > > Don't waste your time on NetApp, threw it away and get a new one >from Auspex. > > If you chose Auspex from the first beginning, you won't have any >problem. > Every things has its price, you got lower price, so they gave >you cheaper service. > Auspex's price may be a liitle bit higher, but you get much >more than you pay. > Auspex's URL : www.auspex.com > > > Good Luck ! > > >Tony Lai >---------------------- >Chief Product Manager >Mitac Inc. > >> This annoys me since I reported last year when I first set up my >> Netapp that NIS >> wasn't working right. Performance was awful, and it was rebinding to >> a >> different NIS slave every couple of seconds. I never heard much back, >> and >> because I immediately switched to using local netgroups I didn't have >> the >> problem again. At least there will finally be a fix. >> >> Dave >> >> > When we first turned on NIS, everything went to hell. The filer >> >> > started denying mounts to all the clients. Unfortunately, it didn't >> do >> > this right away, took several hours. Seems the filer wasn't getting >> >> > netgroup info. Anyway, here's what NetApp told me: >> > >> > > Hi Jason, >> > > >> > > I had one of our escalation engineers look over this >> > > call with me. >> > > >> > > We believe that what you saw when upgrading to 4.1d >> > > is the result of an inefficient method we use to >> > > "lookup" the YP information. Instead of doing 3 or 4 >> > > lookups to get the netgroup info when the mount is >> > > checked we would do one for *every* line in the netgroup >> > > file. >> > > >> > > This behavior has been logged as bug#4088 in our database >> > > and engineering is working to modify the NIS client to >> > > correct this problem. >> > > >> > > For now the recommendation would be to continue using >> > > the local file method which hasn't caused you any >> > > problems. When a fix is available for #4088 then you >> > > could upgrade and begin using the NIS client for >> > > netgroup which should be much faster. One of the >> > > benefits of NIS client is that these lookups should >> > > be faster but with our first release of this NIS >> > > client they simply are not. >> > > >> > > I have flagged this call record as bug#4088 with all >> > > the info you sent to me. The escalation engineer I >> > > spoke with is actually the one that will fix the NIS >> > > code and by flagging your call record as this bug >> > > he can review it during the time he makes the patch. >> > > >> > > This would first be available as a patch release >> > > (a release with a capital D in it such as you >> > > were running prior to upgrading to 4.1d). The >> > > best way to find out when it is available would be >> > > to call back and reference the bug#4088 and ask >> > > if Eirik has a patch for the NIS client yet. I >> > > would think that you might want to wait 30 days or >> > > so -- there is no schedule for a fix date for this >> > > right now. >> > > >> > > Regards, >> > > Gil >> > >> > I never bothered to check back. NOW lists bug #4088 as unfixed. >> >> > Here's our nsswitch.conf which "solved" our problems: >> > >> > # >> > # nfssrv1:/etc/nsswitch.conf >> > # >> > >> > passwd: files nis >> > group: files nis >> > >> > hosts: files nis dns >> > netgroup: files nis >> > >> > Good Luck. >> > >> > --- >> > Jason D. Kelleher kelleher(a)susq.com >> > Susquehanna Investment Group 610.617.2721 (voice) >> > 401 City Line Ave, Suite 220 610.617.2916 (fax) >> > Bala Cynwyd, PA 19004-1122 > > > > >

1 0

Jump to page:

2026

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