toasters

toasters@lists.teaparty.net

13515 discussions

Re: Performance problems
by Devi Nagaraj 15 May '98

15 May '98

How are the NICs on the F520 configured? How are the switch ports configured? Make sure that the duplexes match on both ends. -Devi At 04:09 PM 5/14/98 -0500, Brett Rabe wrote: > >Most of ya'll probably understand what it feels >like to be frustratingly baffled, so pull up >a chair, lend me an ear, and I'll buy ya a beer. > >I've got two NetApps (and two more on order). > >1) F230 > o 5.0R2 OnTap > o 128MB RAM > o 4MB NVRAM > o 5 9-gig drives > o 2 100bT NIC > >2) F520 > o 5.0R2 OnTap > o 192MB RAM > o 4 MB NVRAM > o 9 9-gig drives > o 2 100bT NIC > >The installation is as follows. Both NetApps >are fronted by three FreeBSD servers. One NIC >on the NetApps routes to its own private subnet. >Each of the three servers have a second NIC card >also routing to that subnet. > >I can't get squat for performance from the F520. >I'm not trying to pretend that using 'yes' is a >true benchmark, but it does illustrate the point >sufficiently: > >F520 front-end# yes > /some_nfs_mounted_filesystem/yes >F520> sysstat 1 > CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache > in out read write read write age > 2% 35 0 0 445 8 0 0 0 0 >60 > 4% 36 0 0 468 9 0 0 0 0 >60 > 18% 37 0 0 469 9 1684 816 0 0 >60 > 10% 30 0 0 377 7 96 1632 0 0 >60 > 15% 157 0 0 1457 33 0 0 0 0 >60 > 29% 84 0 0 870 18 1336 2348 0 0 >60 > > >F230 front-end# yes > /some_nfs_mounted_filesystem/yes >F230> sysstat 1 > CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache > in out read write read write age > 68% 287 0 0 1510 823 1052 2300 0 0 >60 > 63% 212 0 0 1683 751 24 1628 0 0 >60 > 67% 248 0 0 1678 811 944 1960 0 0 >60 > 59% 248 0 0 1680 780 1068 1632 0 0 >60 > 59% 214 0 0 1727 804 1048 1760 0 0 >60 > 60% 215 0 0 1684 805 43 2285 0 0 >60 > 53% 202 0 0 1741 783 1052 2328 0 0 >60 > 57% 179 0 0 1416 758 1064 2320 0 0 >60 > >(The F230 also was being backed up and is in >production hosting web pages, in case anyone >notes about all the outbound traffic that wouldn't >be accounted for by 'yes'....) > >The NetApps are configured as close to identical >as reasonable. The version of FreeBSD appears to >be not a factor -- I've got both 2.2.5-RELEASE and >2.2.6-RELEASE that produce the second results on >the F230, and 2.2.5-RELEASE and 2.2.6-RELEASE that >produce the first results on the F520. > >All the interfaces are configured correctly. There >are no significant errors reported by the NetApps, >the FreeBSD boxes, or the network device to which >they all terminate. I can't discern any significant >difference in the FreeBSD box configurations -- if >anything, the fact that I get the same performance >with different FreeBSD OS revs on the F230 and >the same poor performance with different FreeBSD OS >revs on the F520 points to a problem with the F520. > >I had the F230 at 4.3.1 and got similar performance >as I do with 5.0R2. I've gone so far as to swap >ethernet cables. :p > >I'm not sure where to look next; suggestions would >be highly welcomed. I have (of course) hit now.netapp.com >and hunted through their troubleshooting suggestions >to no avail. > >... just another day. :) > >Brett > >--- >Brett Rabe Email : brett(a)uswest.net >Systems Administrator - U S West Phone : 612.664.3078 >Interact - 3S Pager : 612.613.2549 >600 Stinson Blvd. Pager : page-brett(a)uswest.net >Minneapolis, MN USA Fax : 612.664.4770 > > All those who believe in psychokinesis, raise my hand! > > >

4 5

Calculating increase in used space when moving to a filer (long)
by Garrett Burke 15 May '98

15 May '98

Hi All, I'm about to move data from an old&creaking NT server to a F230. I was aware that moving to the filer would lead to a space usage increase due to the larger block size (4K as against 512bytes for standard NTFS) Having searched on NOW, ToolTips and on this list, I bit the bullet and wrote my own script to calculate the space increase. Problem is that a 'du' on a FreeBSD box shows more blocks being used on the filer than I calculated. It's close, but I'd be interested in finding out what the difference is. Someone else must have wrote a script like mine to calculate the change. Is the script missing something (an earlier version missed the space allocated to the directories themselves) or is the filer allocating space for something else. How many directory entries can a 4K directory hold? (There's a total of 337 directories in what I'm running the script on) I have a very deep hierarchy to move. Here's what the script produces when run on a NT 4 SP 3 with a mapped share from a NT 4 SP 3 server. H:\ta\1.60\ NT FS size 216115.695313 KB (3720 files) Netapp FS size 223892.000000 (56311 blocks) KB increase 7776.304688 KB (3%) FreeBSD opc007.msc.ie 2.2-BETA_A FreeBSD (I know, I know, but it's a production box that was up for 80 days before the power went off and on and off and on again) NFS mounted F230 running 4.3.3 opc007:1011#pwd /toaster/releases/ta/1.60 opc007:1012#set | grep BLOCK BLOCKSIZE=4096 opc007:1013#du -s 56505 . opc007:1014# There's a difference of 194, which isn't fixed. It changes for a different hierarchy. The script is below. I know it's not very efficient, but it does run on both NT and UNIX. Use it (Correct it!) if you wish, but at your own risk. (As an aside I'd be interested in hearing from other filer users that are running CIFS, especially in a SW dev environment.) Regards, GB. #!/usr/bin/perl # # Calculate the space used on a filer with 4K block sizes for # the files in the current directory & it`s sub directories # # Based on the example on pages 56/57 of Programming Perl 1st Ed # by Larry Wall and Randal L. Schwartz pub O'Reilly # # Use at your own risk # # Garrett.Burke(a)msc.ie 15/5/98 $blk=4096; # no. of bytes per netapp block &dodir('.'); sub dodir{ local($dir,$nlink)=@_; local($dev,$ino,$mode,$subcount); local(@allfiles); print "Working in $dir\n"; opendir(DIR,'.') || die "Can't open $dir"; @allfiles=readdir(DIR); closedir(DIR); for (@allfiles) { if ($_ eq '.') { # Don`t forget the directories themselves $numblks++; next; } next if $_ eq '..'; $name="$dir/$_"; $fnums++; ($dev,$ino,$mode,$nlink,$uid,$gif,$rdev,$size, $atime,$mtime,$ctime,$blksize,$blocks)=stat($_); if (-d $_) { # print "$name is a directory\n"; chdir $_ || die "Can't cd to $name"; &dodir($name); chdir ('..'); } else { $numfiles++; $nt+=$size/1024; # NT size in KBs (fp) $netappblks=int($size / $blk); # no. of (int)netapp blocks if ($size % $blk) { $netappblks++; # anything over then another block } $numblks+=$netappblks; $netappfs+=$netappblks*4; # FS size (fp) in KB on netapp } } # for @ } if ($nt) { $increase=$netappfs-$nt; # fp printf("NT FS size %f KB (%d files) Netapp FS size %f (%d blocks) KB increase %f KB (%d\%) \n", $nt,$numfiles,$netappfs,$numblks,$increase,($increase/$nt)*100); } -- Garrett Burke, Network Admin,Managed Solutions Corp. 32 Upper Mount St., Dublin, Ireland. burkeg(a)msc.ie +353-1-661-4840 A jug of wine, a loaf of bread and thou.

1 0

Re: Performance problems
by sirbruce＠ix.netcom.com 15 May '98

15 May '98

On 05/14/98 18:56:07 you wrote: > >> What, by the way, is "yes"? > > >YES(1) FreeBSD General Commands Manual YES(1) [etc.] An old UNIX hand once told me yes was originally "designed" for use with the fsck -y option. Whether or not this was true, I don't know. Other things to note - on some systems it's still a C program, on others it's just a shell script. Also, I think some shells have "yes" built-in now. So this can also account for performance differences between OSes. Bruce

2 1

syslog and /etc/messages format
by tjt＠netapp.com 15 May '98

15 May '98

Here at NetApp, we're planning some changes in the way messages are implemented, to provide more specific information (e.g. unique message id's, to identify exactly where messages are coming from), handle things like internationalization, and make it easier to post-process messages. We'd like to know how many people currently have scripts to process the /etc/messages file (and/or any other destinations of syslog or console output). If you would be affected by any changes to the format of /etc/messages or console output, please send me email, so we can take your input into account. Thanks much. ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

2 1

Performance problems
by Brett Rabe 14 May '98

14 May '98

Most of ya'll probably understand what it feels like to be frustratingly baffled, so pull up a chair, lend me an ear, and I'll buy ya a beer. I've got two NetApps (and two more on order). 1) F230 o 5.0R2 OnTap o 128MB RAM o 4MB NVRAM o 5 9-gig drives o 2 100bT NIC 2) F520 o 5.0R2 OnTap o 192MB RAM o 4 MB NVRAM o 9 9-gig drives o 2 100bT NIC The installation is as follows. Both NetApps are fronted by three FreeBSD servers. One NIC on the NetApps routes to its own private subnet. Each of the three servers have a second NIC card also routing to that subnet. I can't get squat for performance from the F520. I'm not trying to pretend that using 'yes' is a true benchmark, but it does illustrate the point sufficiently: F520 front-end# yes > /some_nfs_mounted_filesystem/yes F520> sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 2% 35 0 0 445 8 0 0 0 0 >60 4% 36 0 0 468 9 0 0 0 0 >60 18% 37 0 0 469 9 1684 816 0 0 >60 10% 30 0 0 377 7 96 1632 0 0 >60 15% 157 0 0 1457 33 0 0 0 0 >60 29% 84 0 0 870 18 1336 2348 0 0 >60 F230 front-end# yes > /some_nfs_mounted_filesystem/yes F230> sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 68% 287 0 0 1510 823 1052 2300 0 0 >60 63% 212 0 0 1683 751 24 1628 0 0 >60 67% 248 0 0 1678 811 944 1960 0 0 >60 59% 248 0 0 1680 780 1068 1632 0 0 >60 59% 214 0 0 1727 804 1048 1760 0 0 >60 60% 215 0 0 1684 805 43 2285 0 0 >60 53% 202 0 0 1741 783 1052 2328 0 0 >60 57% 179 0 0 1416 758 1064 2320 0 0 >60 (The F230 also was being backed up and is in production hosting web pages, in case anyone notes about all the outbound traffic that wouldn't be accounted for by 'yes'....) The NetApps are configured as close to identical as reasonable. The version of FreeBSD appears to be not a factor -- I've got both 2.2.5-RELEASE and 2.2.6-RELEASE that produce the second results on the F230, and 2.2.5-RELEASE and 2.2.6-RELEASE that produce the first results on the F520. All the interfaces are configured correctly. There are no significant errors reported by the NetApps, the FreeBSD boxes, or the network device to which they all terminate. I can't discern any significant difference in the FreeBSD box configurations -- if anything, the fact that I get the same performance with different FreeBSD OS revs on the F230 and the same poor performance with different FreeBSD OS revs on the F520 points to a problem with the F520. I had the F230 at 4.3.1 and got similar performance as I do with 5.0R2. I've gone so far as to swap ethernet cables. :p I'm not sure where to look next; suggestions would be highly welcomed. I have (of course) hit now.netapp.com and hunted through their troubleshooting suggestions to no avail. ... just another day. :) Brett --- Brett Rabe Email : brett(a)uswest.net Systems Administrator - U S West Phone : 612.664.3078 Interact - 3S Pager : 612.613.2549 600 Stinson Blvd. Pager : page-brett(a)uswest.net Minneapolis, MN USA Fax : 612.664.4770 All those who believe in psychokinesis, raise my hand!

1 0

Earthlink's NetApp-based email system?
by mer＠world.evansville.net 13 May '98

13 May '98

A few months ago I read an article on NetApp's webserver which was written by an Earthlink engineer. The article described the work that Earthlink had done to build a scalable, reliable email system using NetApp filers. It was interesting to me because it covered in detail the work needed to ensure proper locking across NFS for this application. The article seems to have been removed from www.netapp.com, and none of the search engines I have tried know of it anymore either. Does anyone have an URL (or a copy) they could send me? Thanks, -- Marc Rouleau VP and Chief Technology Officer Voice: (812) 479-1700 Fax: (812) 479-3439 Network WCS http://www.networkwcs.com

2 1

new filer and netcache monitoring tools on NOW site
by tjt＠netapp.com 13 May '98

13 May '98

The Tools&Utilities section of the NetApp NOW site (http://now.netapp.com) has a couple of new tools for monitoring: filer-mrtg A package that uses MRTG for monitoring filers. It provides a web-based interface for current and historical views of: network traffic in/out, NFS ops, disk usage (%), CPU usage, CIFS read/write ops, and CIFS other ops. netcache-mrtg A package that uses MRTG for monitoring NetCache Appliances. It provides a web-based interface for current and historical views of: URLs served, Cache I/O and hit rates, network bandwidth, URL fetch time, cpu and disk space usage, and DNS calls. If you haven't checked out the Tools&Utilities section of NOW lately, it has been enhanced with a number of new tools, and a "Tool Time" effort in which customers are encourage to submit tools (and win a fabulous polo shirt!). ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

1 0

subscribe
by jimy＠hwacomsys.com.tw 12 May '98

12 May '98

1 0

Re: Toasters list - any FAQs?
by sirbruce＠ix.netcom.com 08 May '98

08 May '98

On 05/08/98 21:19:41 you wrote: > >> Also, here's a real item: I'm seeing fairly high >> error and collision rates on my F330's quad ethernet >> card, (10BaseT Quad-Ethernet Controller (Znyx)) and >> was wondering if there are any known issues with this >> card, since the network traffic on these four nets >> does not warrent this high error rate (I'm on OnTap 4.3.1). > >Note that collision is not the same as error! On standard half-duplex >Ethernet, a collision is a normal and healthy phenomenon - simply means >that the Ethernet flow control meachnism is working. > >It's okay to be worried about high error rates. High *collision* rates >(as long as we're not talking about "late collision") aren't really all >that meaningfull by themselves - what you should probably look at is the >*utilization* of the Ethernet segment. I myself have observed high error rates on the Quad 10BaseT card on the filer. It was clearly the largest source of errors on the network, and much higher than I'd ever seen on a normal network. Moreover, it seemed that the error rate increased which each port (I don't quite remember if it went from A to D or D to A) without correlation to the actual amount of traffic on those ports. A bug was filed on this. However, these errors never seemed to actually be a major problem for the network and while I suppose they were responsible for the occasional performance anomaly overall performance of the filer was never a problem. Bruce

1 0

Re: Toasters list - any FAQs?
by sthaug＠nethelp.no 08 May '98

08 May '98

> Also, here's a real item: I'm seeing fairly high > error and collision rates on my F330's quad ethernet > card, (10BaseT Quad-Ethernet Controller (Znyx)) and > was wondering if there are any known issues with this > card, since the network traffic on these four nets > does not warrent this high error rate (I'm on OnTap 4.3.1). Note that collision is not the same as error! On standard half-duplex Ethernet, a collision is a normal and healthy phenomenon - simply means that the Ethernet flow control meachnism is working. It's okay to be worried about high error rates. High *collision* rates (as long as we're not talking about "late collision") aren't really all that meaningfull by themselves - what you should probably look at is the *utilization* of the Ethernet segment. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Toasters list - any FAQs?
by applix!jimsparc!jim＠uunet.uu.net 08 May '98

08 May '98

I'm new to this list, so forgive my ignorance... are there any FAQs or digests of past list submissions that I can come up to speed with??? Also, here's a real item: I'm seeing fairly high error and collision rates on my F330's quad ethernet card, (10BaseT Quad-Ethernet Controller (Znyx)) and was wondering if there are any known issues with this card, since the network traffic on these four nets does not warrent this high error rate (I'm on OnTap 4.3.1). -- Jim Morton, Applix Inc., Westboro, MA jim(a)applix.com

1 0

OnTap FIler OS Upgrade Q's
by Weeks, Thomas 08 May '98

08 May '98

Hi all... Have a NA FS230 box running 4.2aD9... I need to do CIFS inter ACL/UFS-permissions testing and evaluation (for our NFS-->CIFS migration) and was PLANNING on going to 4.3.3 because I do not have a "test box" and wanted to protect myself from the possible "problems" associated with going to the full 5.x release and then trying to back out. (yes.. I am planning on EVENTUALLY going to 5.x, but I want to address one problem at a time (i.e. don't want to have to adress UFS/ACL/locking issues AND variables associates with backing out of the 5.x upgrade.. that's all)) Does anyone have any information on this subject that I should examine? I guess 4.3.3 is no longer the highest pre-5 release version.. but it is now 4.3.4? Anyone? Thanx... Tom Thomas Weeks GTE SYSTEMS ENGINEER Testing-Integration Center "The Pit" Brooks AFB, DSN 240-5444

1 0

DLT7000 stackers
by Amy Chused 08 May '98

08 May '98

Does anyone know how well the Breece-Hill Q1-15 (single drive, 15 cartridges) DLT tape stacker plays with the NetApp 630? Does anyone know how well the smallest StorageTek DLT tape stacker plays with the NetApp 630? I'm about the buy a new netapp and I'm trying to decide between these two tape drives for a locally attached tape drive. Any comments, please? Amy

1 0

F330 running at 100%
by Christoph Doerbeck 04 May '98

04 May '98

Greetings, Today we experienced an F330 pegging at 100% CPU. netstat and nfsstat didn't reviel anything eye popping, and so I'm asking for suggestions as to what might cause this? I would guess that a network interface shouldn't be capable of causing this, but I'll let you tell me.... Here's the system info: ===== SYSCONFIG-V ===== NetApp Release 3.1c: Wed Apr 3 16:40:37 PST 1996 System ID: XXXXXXXX slot 0: System Board 90 MHz (NetApp System Board I) Memory Size: 256 MB slot 0: SCSI Host Adapter 0 (QLogic ISP 1020) 0: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 1: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 2: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 3: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 4: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 5: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 6: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) slot 0: Ethernet Controller e0 MAC Address: 00:a0:98:00:00:20 (100tx) slot 4: Dual SCSI Host Adapter (NetApp SCSI Adapter I) SCSI Host Adapter 4a 0: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 1: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 2: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 3: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 4: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 5: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 6: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) SCSI Host Adapter 4b slot 6: NVRAM (NetApp NVRAM I) Memory Size: 8 MB Battery 1 Status: 100% (3.29v) Battery 2 Status: 100% (3.29v) slot 7: Ethernet Controller e7 (Znyx) MAC Address: 00:c0:95:f8:4b:6c (100tx) slot 8: FDDI Network Adapter f8 (DEC 3002) MAC Address: 08:00:2b:b3:10:71 (Dual Attach Fiber) slot 9: Dual SCSI Host Adapter (NetApp SCSI Adapter I) SCSI Host Adapter 9a 0: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 1: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 2: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 3: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 4: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 5: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) 6: SEAGATE ST15230N 0638 Size=3.9GB (8386733 blocks) SCSI Host Adapter 9b - Christoph

3 4

Re: file locking problem
by Jason D. Kelleher 02 May '98

02 May '98

In message <000801bd74bc$4537cb40$ba032599(a)Ritch.earthlink.net>, "David B. R itch" writes: >We have had numerous problems dealing with SunOS and Solaris mailtool file >locking after moving our mail spool off our Solaris server. Initially, we >moved the spool to a Network Appliance and used a Digital Unix system as the >mail server. In an attempt to solve the locking problem, we moved the spool >to a local filesystem on the Digital Unix box, but we still had problems. >When we switched from binmail to procmail as our mail delivery agent, most >of the problems were resolved. Odd, our problems seem to stem from mailtool / procmail interaction. It doesn't look like mailtool is freeing locks, so procmail can't write to the spool. But this didn't occur (at least procmail didn't complain about) before we moved the spool from the 4.1.3_U1 mail server to the NetApp. >In all of the mess, we learned a couple of things to look for: Is there a >cron job on the Sun that clears locks older than a few minutes? If so, you No, and that shouldn't be necessary. procmail is smart enough to timeout stale locks. >might need a similar workaround on the NetApp filesystem. Are your users >exiting OpenWindows without clicking "Done" (to save changes)? It is a bug >to leave the file locked, but I believe that some versions of mailtool do >this. Do your users find that their mailtools get confused? We found that >to be a symptom of locking problems. Do your users have large inboxes? Our >mailtool and dtmail users have a tendency to keep lots of old mail in their >inboxes, and the resultantly large mail files take longer to update. This >increases the likelihood of two processes needing to lock the file at the >same time. These problems occur while users are running mailtool. We have the latest pathes regarding filelocking installed for SunOS 4.1.3_U1 and Solaris 2.5, 2.5.1, & 2.6. When they exit mailtool, everything is fine. >You might also want to rebuild procmail. When you build it, one thing it >does is to test locking in your mail spool directory, so that it can >determine what locking mechanisms work reliably. It may be that it needs to >run those tests again on your new filesystem. Yep. Already tried it. >On the other hand, you might want to switch to pop3 or imap4 (if possible) >to get mail to your users' workstations. These seem to be more robust >protocols than nfs with locking. If I could just get them to use something other than mailtool, I wouldn't have a problem. pine, elm, nmh, qpopper, and Netscape (movemail) all seem to be ok. mailtool seemed to be fine when mounting from the 4.1.3_U1 spool, now it's brain-dead. >Good luck. Dealing with mail problems can be unpleasant. Tell me about it... Thanks for your help. jason

3 3

file locking problem
by Jason D. Kelleher 01 May '98

01 May '98

This past Saturday we moved our mail spool from a SunOS 4.1.3_U1 system to our NetApp F330 running ONTAP 4.3.3. Since then, we've had problems with procmail processes hanging on open file locks. This only occurs when someone leaves mailtool or dtmail running. Does anyone have any idea why mailtool won't handle file locking when mounting the spool from a NetApp, but will when mounting from a SunOS system? Any insight would be greatly appreciated. jason --- 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

2 1

Re: file locking problem
by sirbruce＠ix.netcom.com 30 Apr '98

30 Apr '98

On 04/30/98 10:59:37 you wrote: > > > > This past Saturday we moved our mail spool from a SunOS 4.1.3_U1 >system to our NetApp F330 running ONTAP 4.3.3. Since then, we've had >problems with procmail processes hanging on open file locks. This only >occurs when someone leaves mailtool or dtmail running. > > Does anyone have any idea why mailtool won't handle file locking >when mounting the spool from a NetApp, but will when mounting from a >SunOS system? > > Any insight would be greatly appreciated. I would try applying the numerous patches for 4.1.3_U1, particularly the NFS patches and the mailtool patches from your descriptions. I might also check out upgrading to 4.1.4 and it's associated patches. Actually, I'm assuming your clients are the same flavor as your old mail spool server. If you have Solaris 2.x clients, there are patches for them as well. If the problem still persists you can talk to Netapp, probably get them a trace and they can find out who isn't doing locking correctly. Bruce

1 0

Re: syslog.conf
by varun＠netapp.com 29 Apr '98

29 Apr '98

> From dfinkels(a)siac.com Wed Apr 29 10:05:13 1998 ... > > Gentle readers, > Before I ask NetApp directly, I was curious if anyone knew of > the > syslog level that NetApp filers use? I want to redirect syslog daemon > messages to a remote host but keep the NetApp-specific messages in a > different file from the regular UNIX system messages. I was hoping it > used something like level1 or level2. If anyone knows the answer I'd be > most appreciative to this kind person. > I'm not sure you can log NetApp specific messages to a different file since the filer uses the same levels as regular Unix systems - (see na_syslog.conf(5)). What you could do is log NetApp specific messages to a remote system and grep for the filer's hostname in the remote system's messages file. It's probably easiest to drive this with a cron script. You might also be interested in Swatch which is a tool (publically available, I think) that allows you to monitor messages files and trigger on user defined events.

1 0

syslog.conf
by dfinkels＠siac.com 29 Apr '98

29 Apr '98

Gentle readers, Before I ask NetApp directly, I was curious if anyone knew of the syslog level that NetApp filers use? I want to redirect syslog daemon messages to a remote host but keep the NetApp-specific messages in a different file from the regular UNIX system messages. I was hoping it used something like level1 or level2. If anyone knows the answer I'd be most appreciative to this kind person. -- Daniel Alex Finkelstein Infrastructure Enhancement Group Systems and Technologies Support phone 212.383.2951 pager 917.427.1630 Securities Industry Automation Corporation

1 0

subscribe
by Lisa Malgeri 29 Apr '98

29 Apr '98

1 0

RE: RAM and NVRAM for F330
by sirbruce＠ix.netcom.com 27 Apr '98

27 Apr '98

On 04/27/98 10:24:26 you wrote: > >> Sounds very much like a shipping issue to me. > > >NetApp Field Support 101: >------------------------- >Practice saying: > >"Of Course We test this hardware! It must be a shipping problem!". > >We've only had one in here for 6 months and I've already learned >that. I don't know if there's anything to it, but it sounds like >a prevalent enough story that NetApp should change their >shipping/handling/packing procedures. Sounds like they've >identified it as a problem to many of us, so how long before >it's fixed? > >-Jeff >(2 bad drives and an EMU shelf with a bad slot in two weeks) If you really want this question answered, you should probably contact Netapp directly, not email this list. While there are employees of Netapp that answer questions here from time to time, it's certainly not the usual channel of communication for addressing issues such as the one you bring up. Bruce

1 0

RE: Budtool to backup netapp
by Weeks, Thomas 27 Apr '98

27 Apr '98

So is ANYONE satisfied with any 3rd party NDMP colutions? IT's a nice fast protocol.. but I'm not seing a lot of support... Is the major advantage with NDMP (besides speed) that it backs up both your ACLs AND your UFS file permissions? Is there any other wayt o do this? Tom D Tek > -----Original Message----- > From: Jason D. Kelleher [SMTP:kelleher@susq.com] > Sent: Thursday, April 23, 1998 9:55 AM > To: Alan Phoenix > Cc: 'toasters(a)mathworks.com' > Subject: Re: Budtool to backup netapp > > In message <17AD4E991EBDD111B6E000A0C99DD8350BA1(a)ntmail05.pc.sas.com>, > Alan > Phoenix writes: > >Has anyone tried using Budtool to backup a netapp? > > Yup. We've been using BudTool to backup our F330 for about 5 > months. We spent a month or two working the kinks out of it before we > let it touch our filer. Here's what we found: > > 1) BudTool's reporting is horrible. End of story. Anyone who > tells you otherwise is either deranged or hasn't actually used > the product. Fortunately, if you know Perl, writing a script > to > parse the logfile and send out a readable report (and page on > fatal errors) is fairly trivial. > > 2) BudTool's built in scheduling could only have been written by a > fool who liked GUIs and never actually had to support a backup > solution in a production environment. cron and a small shell > script handled this problem. (AMANDA has the best backup > scheduling in my opinion. Someday there'll be a vendor who > picks up on it.) > > 3) User level restores aren't supported for NDMP and only work for > UNIX clients if your willing to throw security out the window. > When doing a restore via NDMP, the destination for the restore > has to be on a filer. If your users need to be able to restore > data from tape, pick another product. If you're willing to > pull > stuff off tape for them (the GUIs not bad, but not great > either) > occasionally, then you'll be ok. > > 4) Having one BudTool server control a directly connected 100 tape > DLT400 jukebox, a 5 tape stacker connected to our F330, and a 5 > tape stacker connected to our research departments number > cruncher is pretty nifty. Having all the tape and file > histories in one place is nice too. > > 5) BudTool has a utility called btcp which will copy all your most > current backup requests (Lev 0s and all necessary incrementals) > to a set of tapes for offsite storage. It doesn't just dd a > bunch of tapes. Very nice. Unfortunately, btcp is a little > brain-dead and tries to copy _all_ the requests to one set of > tapes. If you have a couple hundred GB worth of backups, this > can take a really long time. Again, a little shell script > fixed > this problem. > > > All in all, I don't think I've ever been 100% satisfied with any > software product. But BudTool gets the job done (with a little help). > > > jason > > --- > Jason D. Kelleher kelleher(a)susq.com > Susquehanna Investment Group > All opinions expressed are my own, etc, etc...

1 0

RE: RAM and NVRAM for F330
by Jeff Stampes 27 Apr '98

27 Apr '98

> Sounds very much like a shipping issue to me. NetApp Field Support 101: ------------------------- Practice saying: "Of Course We test this hardware! It must be a shipping problem!". We've only had one in here for 6 months and I've already learned that. I don't know if there's anything to it, but it sounds like a prevalent enough story that NetApp should change their shipping/handling/packing procedures. Sounds like they've identified it as a problem to many of us, so how long before it's fixed? -Jeff (2 bad drives and an EMU shelf with a bad slot in two weeks)

1 0

RE: RAM and NVRAM for F330
by sirbruce＠ix.netcom.com 27 Apr '98

27 Apr '98

On 04/27/98 02:48:22 you wrote: >Oddly, out of our 8 netapps, the only one that hasn't had a RAM or >Disk failure is the one with Kingston RAM, Dallas Semiconductor NVRAM >and a number of Seagate drives, all sourced as 'third party'. > >Of our 4 new f230's we got about 5-6 months ago, we've had one dead >NVRAM board, about 2 with bad RAM and I believe 2 ill disks. These >are just off the top of my head and possibly not counting the DOA RAM >issues and another dead NVRAM board I seem to remember hearing about. >Most of these were barely even cracked open by us since receiving them >from NetApp but the problems persisted even after reseating, etc. > >Humourously, the ones with bad RAM sure worked swell when we stuffed >them with cheap Kingston RAM while waiting for the NetApp replacement >'Heavily Tested and Approved' RAM was being shipped. > >We paid extra for this? Yep. For better quality when it leaves Netapp than the parts you get third party. Sounds very much like a shipping issue to me. I'd talk to Netapp support and have them coordinate with shipping to see if that's where the problems are. Given when you say these things occurred, it's quite possible the problems have already been corrected. Perhaps have Netapp ship the seperately, requiring you to install it just like you do third-party RAM, might be a better solution for your given environment. Bruce

1 0

RE: RAM and NVRAM for F330
by sirbruce＠ix.netcom.com 27 Apr '98

27 Apr '98

On 04/16/98 15:48:18 you wrote: > >On Thu, 16 Apr 1998, Weeks, Thomas wrote: > >> RAM on the filer is being run to the very MAX of its specs >> (maybe more)... I hear that they have a fairly high failure rate on RAM >> that would otherwise work FINE in slower, less demanding systems (PC's). > >'scuse me??? Really? I find this somewhat hard to believe... > >60ns RAM is widely available, are you saying they're pushing the envelope >on that? > >I very much doubt the memory architecture on a NetApp is anything more >sophisticated than Sun's memory architecture (and I almost guarantee Sun's >memory architecture blows away low-end NetApps)...and Sun seem able to use >fairly standard parts without too much failure. > >Maybe I'm just missing the big picture... Part of it is history. Back in the "old days", which is to say only 2-3 years ago in computer time, there were lots of vendors you could get 60ns RAM from that weren't quite up to snuff under heavy loads. And those vendors that did often produced RAM that stood up to their tests, but not to Netapp's. As the industry has progressed, I'm sure today's 60ns RAM chips are of higher quality, so failures may be less common than they once were. But yes, Netapp seriously pushes the performance of memory under high load, even if that is now more easily within the tolerances of most memory chips. Another thing to consider is that if you don't run your filers under very high load, it's probably very easy for you to "get away" with lower-quality memory. But don't be surprised if your filer starts getting memory errors once you start running your CPU at 100%, or your cache age at 1, or you have a disk failure and have to do reconstruction while in service, etc. Bruce

2 1

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