toasters September 1999

toasters@lists.teaparty.net

81 participants
95 discussions

NDMP utility for tape robots
by grdodson＠lexmark.com 15 Sep '99

15 Sep '99

Back in early June there was some discussion on this list about how to control a tape robot attached to a NetApp. At that time I stated that it could be done via NDMP and that I had done it, but could not release my code to the public. With the help of a prod from Dan Warmenhoven (NetApp's CEO) I was able to convince the corporate layers to let me release the code. After cleaning it up (to prevent personal embarrassment) I send it to NetApp and they have now posted it. The source and SPARC binaries can be found on NOW under the "Tool Time ToolShed" section. http://now.netapp.com/download/tools/ndmputil The program ONLY supports manipulating a robot, it does NOT support dumping via NDMP. This is all the functionality I needed or wanted. It also may be a blessing in disguise, all the ugly NDMP bugs I have heard about are dump related. I hope someone else out there finds the program useful. Consider it a thank you for the help I have received from this list in the past. But don't expect me (or my employer) to provide ANY support, I don't have time, sorry. Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc.

1 0

Re: Best way to copy data to new filer ??
by Luke Mewburn 15 Sep '99

15 Sep '99

"David H. Brierley" writes: > I am getting ready to convert from an F220 and an F230 to an F740. > Does anyone have any recomendations on how to copy all of the data > from the two old filers to the new one? I know I can use dump and > restore but I was wondering if maybe "vol copy" would be more > efficient. Can I use "vol copy" to copy the entire contents of > two existing filers to a single new one? If so, can it merge the > contents into a single volume or should I create multiple volumes? I've used vol copy when the target volume is to be totally overwritten by the source volume. When merging multiple volumes, ndmpcopy might be of some assistance (I can't remember enough about my experiences with it). A general principle I use for data migration on UNIX (and can be done on the filers with little effort) is: cd /dest dump 0f - /src | restore xf - (make src & dest unavailable for the rsync) rsync -vaxH --delete /src/ /dest/ (bring dest online). rsync is an extremely useful tool, by the same person who gave us samba (Andrew Tridgell). It can be found at: http://rsync.samba.org/ It does a great job of copying only the bits that have changed. I use it as a poor man's snapmirror ;-) Hope that helps, Luke.

2 1

Have you had problems with 5.2.3 OS???
by Linda Walton 15 Sep '99

15 Sep '99

I currently have a 520 problem-child that occasionally reboots during the weekly dump. (we use scripts running from cron on the Solaris adminhost) At this time, we are running on release 5.2.2P1D4 and I've heard that Network Appliance is recommending that all customers migrate to 5.2.3 OS. Before I upgrade the filer (which will require a firmware upgrade and a disk promcode upgrade), I want to get some feedback from anyone running 5.2.3. (especially on a 520) Linda Walton; UNIX System Administrator Reasoning, Inc.

2 1

(151)Stale NFS file handle
by Robert Johannes 14 Sep '99

14 Sep '99

Dear Group; I'm running into a situation with the Netapp filer 740. I have a directory on the netapp called /www/C_name , and this directory gets mounted on two webservers. I've been running into a problem where the webserver randomly denies acess to some files, returning a "Forbidden" message. The strange thing is the files for which access is denied have the right permissions: I looked through the error log file and noticed that foreach of the files whose access had been denied, the webserver logged a message saying: (151)Stale NFS file handle: access to /www/C_name/file_name failed. But when the webbrowser reloads the requested file a couple of times, the file is eventually displayed. I also looked through the system log files, and there was no log of any kind mentioning a stale nfs file handle. I mean that the nfs file system was/is intact, but some how, the webserver could not access the file. What I'm wondering about: Is there a situation that would cause the netapp filer to deny access to the webserver machines for a few miliseconds, thus coincidentally causing the webserver not to serve the requested file? What would lead to a situation like this? Any pointers/suggestions/comments/help very much appreciated. Sincerely, Robert Johannes

2 1

Re: Have you had problems with 5.2.3 OS???
by Yicheng Li-R37424 14 Sep '99

14 Sep '99

Do you mean 5.2.3 or 5.3.2? LOL!! We're running an F540 and recently upgraded to 5.3.2D3. Previous to that, we were running 5.3 and suffered the same kind of spontaneous reboot problem during nightly backups(according to NetApp, due to an NDMP bug in the OS). We first upgraded to 5.3.2, and it stopped crashing but our backups (we're using Budtool) still reported bad dumps. After upgrading 5.3.2D3, however, things seemed to have gone back to normal. As far as I know, 5.2.3 was pretty stable, though it had some NIS compatibility problems. One interesting quirk is that the upgrade process seemed to have over-written my existing /etc/rc file. After the first reboot, I had to go back and manually start CIFS and HTTPD. Another note is that OnTap seems to be migrating more and more configuration information out of the configuration files and to system "registries" where we can't hack at them anymore. Filer View and command line "config/setup" tools seem to be the prefered way to go. > From: Linda Walton <lwalton(a)reasoning.com> > Date: Tue, 14 Sep 1999 10:34:12 -0700 (PDT) > To: toasters(a)mathworks.com > Subject: Have you had problems with 5.2.3 OS??? > > I currently have a 520 problem-child that occasionally reboots during > the weekly dump. (we use scripts running from cron on the Solaris adminhost) > At this time, we are running on release 5.2.2P1D4 and I've heard that > Network Appliance is recommending that all customers migrate to 5.2.3 OS. > Before I upgrade the filer (which will require a firmware upgrade and > a disk promcode upgrade), I want to get some feedback from anyone running > 5.2.3. (especially on a 520) > > Linda Walton; UNIX System Administrator > Reasoning, Inc. ---------- Yicheng Li Motorola SPS WISD Engineering Network

1 0

NFS client tuning, problem and resolution.
by Nick Christenson 14 Sep '99

14 Sep '99

Recently, we encountered a serious problem in a high performance NFS environment using large Solaris servers as NFS clients. Due to the fantastic assistance of several people who have elected to not be named, we have identified the problem and a resolution for it. Since others on this list are likely to use Solaris servers as NFS clients in high performance environments, it was thought that this information might be generally useful. Situation and Symptoms: We were running on E class Sun's using Solaris 2.6 with what we thought were well considered kernel tuning parameters (cranked up nfs:nfs_max_threads, maxusers, rlim_fd_{max,curr}). The disks were using Sun's Gigabit Ethernet interfaces connecting to NetApp F760s using a high quality Gb Enet switch. When we turned the application on, we got stunningly low throughput numbers, and couldn't figure out why. Client CPU load was very good, most of the processing power was idle (and not in WAIT state), memory utilization was low, the filers were running at low utilization, there were no network or I/O bottlenecks in evidence. We were running two applications that do reads, writes, appends, creates, and deletes on relatively small files over NFS. One of these applications, and both have fairly similar characteristics and perform computations on the same file sets, was running just fine. The other was running well at light loads, but had horrible problems as the load went up. It appeared that some fixed resource was being consumed, and once we went over a certain load threshold, the number of processes grew exponentially while the amount of work being done remained constant. Eventually, these extra processes exhausted main memory and the machine began to thrash. Solution: Since we don't have access to Sun source, we can't be 100% certain of what was happening, but this is the best information we have. We think what we describe here is exactly what's going on, but there might be some minor variations. If someone here knows Sun internals, maybe they can fill in the gaps. Basically, it seems that we were having problems with the Directory Name Lookup Cache (DNLC) in Solaris. It seems that between Solaris 2.5.1 and Solaris 2.6 the math was changed on how this was calculated. Here's the math, as best I know it: 2.5.1 DNLC size = (max_nprocs + 16 + maxusers) + 64 2.6 DNLC size = 4 * (max_nprocs + maxusers) + 320 According to Cockroft's Sun Performance Tuning book, max_nprocs = 10 + 16 * maxusers We don't know if this calculation has changed between 2.5.1 and 2.6 Wanting large numbers of processes and large buffer sizes, we set maxusers=2048. This means that for Solaris 2.5.1, the DNLC size would be 34906 (or so) and for Solaris 2.6, the same maxusers variable would yield a size of 139624. Now, as we understand it, this is a LINEAR lookup table. Further, when deleting a file, an entry in this table must be looked up and locked. This was the distinction between our two processes, one does a single delete before completion, the other does three deletes. With a table this size, there seems to be a finite number of deletes/second one can perform over NFS, and we hit that limit. We put "set ncsize = 8192" in /etc/system, rebooted, and the problem went away. We played with sizes ranging from 4096 to 32768 and saw no huge performance difference, (8192 SEEMED best, 32768 SEEMED worst, but that was a VERY subjective evaluation), and we saw no significant difference to our DNLC cache hit rate as measured by "vmstat -s". Additional Information: One way you can look to see if you're experiencing this problem is to run "/usr/ucb/ps -uaxl" and look at the WCHAN column. To the best of our knowledge, Sun doesn't publish a translation guide to these event names, but we have it on good authority that if you see one called "nc_rele_" (which is a truncation of "nc_rele_lock") the process is waiting for DNLC entries to become unlocked. Note: On healthy machines processes will sometimes show up in this state, but if a significant percentage of them are in this state, that may indicate this problem. No, I can't accurately define "significant state". I doubt 1% is a problem, I know that 30% or higher is a problem. Also, Sun has a BugId for this problem, 4212925. As of August 2, they have a patch for 2.6, numbered 105720-08. It seems to do a lot of things, but the explanation of it isn't as revealing as we'd like, so we're a little leery of putting it into production without extensive testing. We're playing with it, but can't comment on it's efficacy at this time. It might hash the DNLC table (That would be the right solution, and word is this will happen in 2.8), but for all I know it may just revert to 2.5.1's DNLC math. Summary: If you're running Solaris 2.6 or 2.7 in a high performance environment where a lot of files are being deleted over NFS, make sure your DNLC is not too large or you'll have HUGE problems. Trust me. Hope this helps someone. -- Nick Christenson npc(a)sendmail.com

5 4

RE: Best way to copy data to new filer ??
by Melvin, Grant 14 Sep '99

14 Sep '99

Hi David, Check out the "Migrating Data Between NetApp Filers" technical report (#3018) at: http://www.netapp.com/tech_library/3018.html Hope this helps. Cheers, Grant -----Original Message----- From: David H. Brierley [mailto:dhb@ssd.ray.com] Sent: Tuesday, September 14, 1999 9:19 AM To: toasters(a)mathworks.com Subject: Best way to copy data to new filer ?? I am getting ready to convert from an F220 and an F230 to an F740. Does anyone have any recomendations on how to copy all of the data from the two old filers to the new one? I know I can use dump and restore but I was wondering if maybe "vol copy" would be more efficient. Can I use "vol copy" to copy the entire contents of two existing filers to a single new one? If so, can it merge the contents into a single volume or should I create multiple volumes? -- David H. Brierley Raytheon Systems Company - Portsmouth RI Facility Work: dhb(a)ssd.ray.com Home: dave(a)galaxia.com

1 0

Upgrades
by Jay Orr 13 Sep '99

13 Sep '99

I had recently done an upgrade from 4.2a to 5.3.2r1, and now when it is backing up, Budtool reports : 09/13/99 09:31:46> DUMP: creating "/vol/vol0/../snapshot_for_backup.7" snapshot. 09/13/99 09:32:08> ------------------------------------------------------------------ 09/13/99 09:32:08> ------ W A R N I N G ------- 09/13/99 09:32:08> Unexpected log entries 09/13/99 09:32:08> DUMP: Using subtree dump 09/13/99 09:32:08> ------------------------------------------------------------------ 09/13/99 09:32:09> DUMP: Date of this level 1 dump: Mon Sep 13 09:32:07 1999. 09/13/99 09:32:09> DUMP: Date of last level 0 dump: the epoch. 09/13/99 09:32:09> DUMP: Dumping /vol/vol0/ to standard output Last backup was a level 2 and it did the same (redid level 0). Can anyone tell me what's going on here? ----------- Fujitsu - Nexion, St. Louis, MO Jay Orr (314) 579-6517

2 2

NetApp versus Dell
by Colm Buckley 13 Sep '99

13 Sep '99

Quickie from someone in the last stages of speccing and sourcing filer solutions... has anyone got any experience of the Dell PowerVault NAS systems? They look very much like re-badged NetApp F720-F760s, with one or two small differences. Anyone have any points either pro or con these systems, versus the NetApp equivalents? Colm -- Colm Buckley B.A. B.F. # colm(a)tuatha.org colm.buckley(a)cs.tcd.ie Department of Computer Science # +353 87 2469146 # whois cb3765 Trinity College, Dublin 2, Ireland. # http://www.tuatha.org/~colm/ Don't put all your hypes in one home page.

2 1

Q on disk firmware level
by George Kahler 13 Sep '99

13 Sep '99

Could some kind soul who is running ST39173W disk drives (probably on a F520) tell me what the disk's firmware level is? Much appreciated, George ------------------------------------------------------------------------------- George Kahler e-mail: george(a)yorku.ca Sr. Systems Administrator humans: (416) 736-5257 x.22699 Computing Services, York University machines: (416) 736-5830 Ontario, Canada, M3J-1P3

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 September 1999