toasters May 1998

toasters@lists.teaparty.net

43 participants
53 discussions

Re: Botched filer upgrade
by sirbruce＠ix.netcom.com 17 May '98

17 May '98

On 05/16/98 15:05:47 you wrote: > > >Hey folks. > >I just got some gigabit ethernet cards to replace my fddi >back-end network. The install went well (trivial) but all >release, non-5.x, DataONTAP versions have some bugs with >the gigabit ethernet. > >So, I upgraded to 4.3.4D2 which supposedly has the fix. >It works well on my f540. > >My f630 pukes horribly: > >Probing devices >Finding image... >Loading 14 f 5 disk@0 >Complete >Starting NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 >Copyright (c) 1992-1998 Network Appliance, Inc. > >PANIC: MM fault MMCSR=1, type=1, VA=0x79dba0, PC=0xfffffc00002a2d44 > > >version: NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 >cc flags: 1 >dumping core: Error dumping core --- not dumped. > >ok c > > >I quickly put the 4.3.3 boot floppy I had and we are back in service >and I am calming down.. :) > >So, anybody able to decode this error? It's a pretty brutal error that you probably can't do anything to fix. Since 4.3.4D2 is unreleased and a patch you got from support (I assume) particularly to address a Gigabit problem, then my guess it was never tested on a 600 series. So you really need to talk to tech support and let them know of the error and ask when a version of that will be available for the 600 series. :) Bruce

1 0

Re: Support for Network Time Protocol?
by sthaug＠nethelp.no 16 May '98

16 May '98

> >Yes. NTP for everything, including our Cisco routers. Keeps the time nicely, > >and doesn't step it. It would be *much* nicer to have NetApp support use > >NTP also. > > Okay, I was just curious. Most places I've seen aren't as "religious" about > the use of NTP. Not that there's anything wrong with that. :) Nothing religious about it, actually. We have a well established NTP infrastructure, we've used NTP for many years and are very comfortable with it. Thus we'd like to use it for NetApps too. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Botched filer upgrade
by Alexei Rodriguez 16 May '98

16 May '98

Hey folks. I just got some gigabit ethernet cards to replace my fddi back-end network. The install went well (trivial) but all release, non-5.x, DataONTAP versions have some bugs with the gigabit ethernet. So, I upgraded to 4.3.4D2 which supposedly has the fix. It works well on my f540. My f630 pukes horribly: Probing devices Finding image... Loading 14 f 5 disk@0 Complete Starting NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 Copyright (c) 1992-1998 Network Appliance, Inc. PANIC: MM fault MMCSR=1, type=1, VA=0x79dba0, PC=0xfffffc00002a2d44 version: NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 cc flags: 1 dumping core: Error dumping core --- not dumped. ok c I quickly put the 4.3.3 boot floppy I had and we are back in service and I am calming down.. :) So, anybody able to decode this error? My filer is: whirlpool> sysconfig -v NetApp Release 4.3.3: Mon Mar 16 12:58:27 PST 1998 System ID: 0016786960 slot 0: System Board (NetApp System Board IV rev-b) Firmware release: 1.8_a1 Memory Size: 512 MB slot 2: Ethernet Controller e2 (Znyx) MAC Address: 00:c0:95:f8:2f:6d (Twisted pair) slot 3: FDDI Network Adapter f3 (DEC 3002) MAC Address: 00:00:f8:bd:c6:04 (Dual Attach Fiber) slot 8: Dual SCSI Host Adapter (NetApp SCSI Adapter I) SCSI Host Adapter 8a (Qlogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. 0: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 1: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 2: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 3: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 8: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 9: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 10: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 11: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 12: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) EMU 0: P/N 500408 S/N 2550270236 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events EMU 1: P/N 500408 S/N 2550272530 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events SCSI Host Adapter 8b (Qlogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. 0: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 1: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 2: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 3: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 9: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 10: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 11: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 12: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) EMU 2: P/N 500408 S/N 2550272276 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events EMU 3: P/N 500408 S/N 2550272259 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events slot 9: NVRAM (NetApp NVRAM II) Revision: A1 Serial Number: 9744 Memory Size: 16 MB Battery 1 Status: 100% (3.30v) Battery 2 Status: 100% (3.29v) slot 10: Gigabit Ethernet Controller e10 MAC Address: 00:60:cf:20:48:61 (1000fx) whirlpool> I need gigabit pretty badly but don't want to go to 5.x yet. Anybody? Thanks. Alex

1 0

Re: Support for Network Time Protocol?
by sthaug＠nethelp.no 16 May '98

16 May '98

> It is a little bit of a hassle, but rsh rdate works pretty well. Any reason > why you don't want to use it? Do you use NTP for the rest of your environment? Yes. NTP for everything, including our Cisco routers. Keeps the time nicely, and doesn't step it. It would be *much* nicer to have NetApp support use NTP also. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Calculating increase in used space when moving to a filer (long)
by Keith Brown 15 May '98

15 May '98

>I'm about to move data from an old&creaking NT server to a F230. >Iwas 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) This is not necessarily the case, and almost certainly wouldn't be the case for most installations/migrations. "Standard NTFS" would very *rarely* be using an allocation unit size of 512 bytes on most modern systems. The way NTFS figures out the default allocation unit size to use on a particular disk or volume-set is quite simple, if you can remember the "kilobyte to gigabyte" correlation that exists. Specifically, NTFS uses an allocation unit size of half a kilobyte on disks of half a gigabyte or less (rare these days, right? :-)), one kilobyte on disks of one gigabyte or less, two kilobytes on disks of 2 gigabytes or less, and 4 kilobytes thereafter. Unless you manually created your NTFS file systems using something along the lines of a: C:\> FORMAT d: /fs:ntfs /a:512 to override the default and force an allocation unit size of 512 bytes, then your NTFS file system will likely be using the same default allocation unit size as WAFL uses (4Kb). Also, don't forget the swings-and-roundabouts issues that are normally associated with small AU sizes. There's a reason that AU sizes generally get bigger as file system sizes increase. Smallers AU's cause most file systems to burn more AU's to keep track of the AU's, if you see what I'm saying? :-) It is often hard at best, and impossible at worst to accurately account for such matters in application level scripts that just read "visible stuff", but I don't think that you'll find that WAFL and NTFS are fantastically different space burners for the vast majority of situations.* If you do, well.... let me know, *especially* if WAFL proves far superior.... :-) Keith

1 0

Support for Network Time Protocol?
by Mike Mueller 15 May '98

15 May '98

We recently observed some strange behavior due to the filer's clock being about 1 minute and 30 seconds faster than a client's. The dates displayed by 'ls -l' of files that had been recently created were listed as "May 14 1998" instead of "May 14 18:22" like they should be. It is important that NFS clients and servers have the same time. We would prefer to use NTP for time synchronization on the NetApp instead of running a cron job on a UNIX server that will fire off a 'rsh rdate' command on the filer. Does anyone know about any NetApp plans to support NTP? -- Mike

1 0

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

15 May '98

> for one reason. There isn't an appendix which contains a _complete_ > list of all error messages and sample _syntax_ in the filer > documentation. ... > So, I'm all for more specific messages -- as long as they are > documented. Please. Thanks for the input. Yes, it's our intention that unique message ids be usable for looking up information about the messages, implying that there is a database of all messages that can used in a variety of ways, including documentation. ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

1 0

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

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