toasters

toasters@lists.teaparty.net

13531 discussions

RE: tech support waits
by sirbruce＠ix.netcom.com 20 Sep '99

20 Sep '99

On 09/19/99 21:35:17 you wrote: > >Steve, >I can see how the "proactive" response to a disk failure autosupport would leave >you rather unimpressed when the call back is after you have already acted on it >yourself! Fact of the matter is, that is indeed the way it is today. Autosupport >is filtered by a script and the ones needing attention (eg DISK_FAIL) are >forwarded to CSRs for attention. A call is logged and the customer is contacted. >Now, the info in the autosupport is not very CS-friendly because the info that >we need to locate the customer is not mandatory. So, often it slows down the >process of logging the call, finding the contact information, etc. In other words, Network Appliance implemented autosupport without committing to the staffing necessary to support all of the events generated. The solution then is either to ditch autosupport, or increase staffing. Productivity enhancements to the process (i.e. automation) are fine, but are not enough by themselves in the long term unless the fundamental issue is resolved. >We are looking at correcting these bottleencks by proposing changes to >Engineering that would make contact and customer information mandatory in >autosupport. So your solution is to shift more work off to the customer? Not a good strategy. You should keep it optional so that customers can still get *some* benefit out of autosupport if they chose, even if it means Netapp won't be able to respond their quickest. A simple note in the documentation making it clear that the more information the better would be sufficient. Furthermore, the customer information is not going to be kept up to date by many sites. IT professionals have too much to do as it is; one reason why *you* are paid for *support* is so that *you* do some of that work. It is not unreasonable for support to try to keep their records updated. >We also have a team engaged right now to scope out automation >around autosupport. If, for example, locating a customer record in our database >was simple and guaranteed (programatically) then a script could field the >DISK_FAIL autosupport, log a call, check the customer's service level, issue the >RMA and email you back the call log number and the shipment info. (Know anyone >that could help us with this project? :-). This sort of automation should have been done years ago. Doing it now depends a lot on your choice of customer database and may require a new one if your old one was not properly planned. As to who can help you, you're in the heart of Silicon Valley... look out the window and wave some stock options around. Or consider offer existing personnel additional incentives to do the task. (Why do we have to tell you this?) >We are also thinking about automating the analysis of a crash - I think we >should be able to suggest patches just based on info in autosupport ... at least >some percent of the cases. Not sure how successful this will be. But it would be >really cool even if we were able to auto-analyze and propose upgrades for 25% of >the cases! This is a good idea. The wording will have to be careful to distinguish between "This looks like a known bug and we think this upgrade may fix the problem" and "We don't know specifically about this problem, but it may be fixed by going to the latest recommended version" and also catching those cases where the latter advice might actually be unwise. This can help in the response time but in many cases you will ultimately need some actual human intervention to follow-up. >This should be possible. Autosupport has a lot of untapped benefits that we can >take advantage of. It is not straightforward - but you should see some changes >in the future - for the better. Look, I know this message sounded harsh. No need to respond. But I recognize corporate PR song and dance when I see it and it pushes one of my hot buttons to see it on this list. Looking at resolving the problem? It's been around for a long time. Considering more automation? I bet you would have said the same thing 5 years ago. Explanations are fine, but excuses are just excuses. Customers want to see results. Bruce

2 1

RE: tech support waits
by Datta, Diptish 20 Sep '99

20 Sep '99

Steve, I can see how the "proactive" response to a disk failure autosupport would leave you rather unimpressed when the call back is after you have already acted on it yourself! Fact of the matter is, that is indeed the way it is today. Autosupport is filtered by a script and the ones needing attention (eg DISK_FAIL) are forwarded to CSRs for attention. A call is logged and the customer is contacted. Now, the info in the autosupport is not very CS-friendly because the info that we need to locate the customer is not mandatory. So, often it slows down the process of logging the call, finding the contact information, etc. We are looking at correcting these bottleencks by proposing changes to Engineering that would make contact and customer information mandatory in autosupport. We also have a team engaged right now to scope out automation around autosupport. If, for example, locating a customer record in our database was simple and guaranteed (programatically) then a script could field the DISK_FAIL autosupport, log a call, check the customer's service level, issue the RMA and email you back the call log number and the shipment info. (Know anyone that could help us with this project? :-). We are also thinking about automating the analysis of a crash - I think we should be able to suggest patches just based on info in autosupport ... at least some percent of the cases. Not sure how successful this will be. But it would be really cool even if we were able to auto-analyze and propose upgrades for 25% of the cases! This should be possible. Autosupport has a lot of untapped benefits that we can take advantage of. It is not straightforward - but you should see some changes in the future - for the better. Diptish Datta Director, Product Support Network Appliance > -----Original Message----- > From: armijo(a)cs.unm.edu [mailto:armijo@cs.unm.edu] > Sent: Thursday, September 16, 1999 7:23 PM > To: jay(a)cimedia.com > Cc: toasters(a)mathworks.com > Subject: Re: tech support waits > Importance: High > > > > > > I opened another case on the same day that was resolved that > > week. Interestingly, on this second case, NetApp also > opened a case on > > my behalf over the same issue in response to an autosupport email my > > NetApp generated when it crashed. > > > > NetApp is extremely inconsistent about this. Our filers > have probably > > crashed a half dozen to a dozen times in the couple of years we've > > owned them and this is the only time I've seen the autosupport email > > cause a case to be opened. > > I have seen the same thing. I had a filer throw a disk one > night, I called > in, got a disk sent to me, got it 6 hours later( our support > contract says > 4 ), and dropped it in place. then the next day i had > someone from netapp > call me with an open case and explain they wanted to ship me > another disk, > and had a new case opened for me. > > other times i have had a filer reboot on random crashes, and > never heard > a thing. > > on th eother hand, it is nice to be able to get a warm body > on the phone 24 > hours a day, now if only there was a way to escalate faster... > > -steve > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] >

1 0

RE: Best way to copy data to new filer ??
by Vine, Ben 17 Sep '99

17 Sep '99

Depending on the size of your data, and the downtime you are willing to stand, you might want to use SnapMirror as the migration tool. It has the disadvantage of not being able to merge 2 volumes, but it is definitely the best way to migrate with minimum downtime. Ben Vine SE & Support Manager, ISRAEL Network Appliance Tel: +972-54-759007 Email: bvine(a)netapp.com What doesn't kill you, makes you stronger... -----Original Message----- From: David H. Brierley [mailto:dhb@ssd.ray.com] Sent: Tuesday, September 14, 1999 6:19 PM 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

Re: tech support waits
by Skinner, Alistair 17 Sep '99

17 Sep '99

Hi Todd, My name is Alistair Skinner. I run the global support center at Network Appliance, and was passed your comments concerning the our email responsiveness and holdtimes. Thanks for taking the time to give us some feedback. I'll make sure we follow up with you on your specific support cases, but wanted to let you know what we're doing generally on web access and phone holdtimes. Our preferred method of online access is through the web. Using the email option from within a case view gives you a pre-formatted subject line to make sure the email is attached to the case in our system. The comments field can also be used. Unfortunately currently there can be up to a day delay between you submitting something and it getting into our system as these updates are batched. We expect to have an enhanced version implemented in the next two months which will include immediate updates directly to the case. Regarding phone responsiveness, due to our continued growth, we still experience some long holdtimes at certain times of the day. We have 10 new staff who will complete their training over the next few weeks, and we are in the middle of reallocating existing staff within the various specialty groups to better match resources to demand. Additionally this week we have changed our process behind the "the filer is not serving data" option - instead of queuing blindly for the next available support engineer, these calls are now routed to our customer support group who will connect you directly with a support engineer if your system is down. I also wanted to let you know as an additional resource, if you have concerns about how a case is being handled, you can call 1-888-4NETAPP, select the "new case" option, and ask to speak to the Duty Manager. Thanks again for your feedback, Alistair Alistair Skinner Network Appliance alistair.skinner(a)netapp.com 408-822-6339

4 3

Is the Postmark source code stilll available?
by sthaug＠nethelp.no 17 Sep '99

17 Sep '99

The Postmark source code, referenced from http://www.netapp.com/tech_library/postmark.html http://www.netapp.com/tech_library/3022.html appears to be no longer available from the Netapp web site. The source code is supposed to be at http://www.netapp.com/ftp/postmark-1.11.c.gz but this URL gives a 404 Page not found error. Does anybody know if the Postmark source code is still available? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 2

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

15 Sep '99

Nick Hilliard writes: > The other problem with it is that if you've got lots of files, it tends to > consume vast amounts of memory. Last time I used it for syncing a large > volume (over 3M files), it required about 600 megs of memory (for which swap > works fine). Yes, that's true. It can also get a bit CPU bound. That's why it can pay to break up the rsync into multiple processes (one for each subdir) and split them across multiple processors.

1 0

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

Re: NetApp versus Dell
by sirbruce＠ix.netcom.com 13 Sep '99

13 Sep '99

On 09/13/99 14:48:27 you wrote: >At present they are re-badged systems with different shelves. They were >much cheaper here than NetApp's though I don't feel that Dell have >their routines completely sorted out yet so there can be some logistic >hassles with your purchase. IIRC their European plant is in Ireland so >you may have an advantage there. Dell seem best at delivering shrink >wrapped solutions. I have heard of problems with Dell sales & support as well. For instance, one customer who specifically said they wanted to use a Dell system to support their Microsoft SQL database wound up going with SAN and another vendor because they were not informed of Microsoft allowing NAS support for their SQL database on Netapp filers specifically. Bruce

1 0

Re: NetApp versus Dell
by Michael Salmon 13 Sep '99

13 Sep '99

+----- On Mon, 13 Sep 1999 13:11:16 BST, Colm Buckley writes: | | 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? At present they are re-badged systems with different shelves. They were much cheaper here than NetApp's though I don't feel that Dell have their routines completely sorted out yet so there can be some logistic hassles with your purchase. IIRC their European plant is in Ireland so you may have an advantage there. Dell seem best at delivering shrink wrapped solutions. Pro: much cheaper. Con: Dell is an uncertain quantity as yet. /Michael

1 0

Re: maxfiles increase - good rule of thumb?
by sirbruce＠ix.netcom.com 13 Sep '99

13 Sep '99

On 09/12/99 21:09:53 you wrote: > >Greetings, > >We're about to hit 100% in inode usage again and this time, I want to >increase `maxfiles' to a more reasonable level than the current 1 per 32KB >allocation. > >The average file size on our 216GB volume is ~4KB. But I think increasing >maxfiles by 8 times might be a bit risky. Or maybe not. Anyone ever >increase maxfiles from 1 per 32KB to 1 per 4KB? > >Just to play it safe, I'm thinking of doing it in 4KB increments... first >increase to 1 per 28KB and then work my way up if I need it. > >Suggestions or testimonials? I don't think this is the best approach to use. Rather, consider how full your filesystem currently is. If you're using 50% now, then a simply extrapolation is to simply double the current maxfiles number (don't think in terms of inodes/KB) and you should be fine. Or, if you don't want the hassle of monitoring your maxfiles, consider the max expansion for your filer and adjust upward based on current usage. The space/performance penalty for having a maxfiles a few times larger than you actually use is minimal. Personally, whenever I've had a filer go over 90% inode usage, I would generally just bump maxfiles up by 50% (total) if the disk is also close to getting full, or double it if I have a new filer that I am planning to add a lot more to in the near future. Bruce

1 0

maxfiles increase - good rule of thumb?
by Kevin Ying 12 Sep '99

12 Sep '99

Greetings, We're about to hit 100% in inode usage again and this time, I want to increase `maxfiles' to a more reasonable level than the current 1 per 32KB allocation. The average file size on our 216GB volume is ~4KB. But I think increasing maxfiles by 8 times might be a bit risky. Or maybe not. Anyone ever increase maxfiles from 1 per 32KB to 1 per 4KB? Just to play it safe, I'm thinking of doing it in 4KB increments... first increase to 1 per 28KB and then work my way up if I need it. Suggestions or testimonials? ~~~ Kevin Ying / Sysadmin Team Leader interQ, Inc. kevin(a)interq.or.jp Infoss Tower 10/F (vox) +81-3-5456-2555 20-1 Sakuragaoka-cho (fax) +81-3-5456-2556 Shibuya-ku, Tokyo 150-0031, JP

2 1

Re: local vs. network backup for F740's
by sirbruce＠ix.netcom.com 11 Sep '99

11 Sep '99

On 09/10/99 10:50:46 you wrote: > >Hi all. > >We have several F740's with about 400GB each, and we are reexcamining >our backup strategy. I would prefer a centralized, network backup over >a dedicated backup network. I don't understand the difference between the two. I mean you can have both. I suppose by the former you mean doing it over your regular network instead of a new one, which is fine, so long as you have the bandwidth for it. >We've heard rumours that the only >reasonable way to backup filers is using a locally attached DLT drive, >and that we must buy an expensive ($700) NetApp SCSI controller card >before we attempt to do a local backup. AFAIK, the 740 should have come with a tape backup card that supports something like 2 tape drives. Just make sure you have the right kind of SCSI for it. >Does this make sense to you >all? What is the conventional wisdom on the ideal way to backup >multiple filers? Personally, I prefer the local backup, depending on your backup scheme. You can back up everything at once without drive or bandwidth contention and the cost is not outrageous. But if you want to use network backup, I think that is fine too. However I would be wary of using NDMP, which historically has had problems. Then again, if you are using a centralized tape robotic and want all the features and stuff, NDMP may be your only choice. Bruce

1 0

Re: Uses for an old Storageshelf 1?
by sirbruce＠ix.netcom.com 11 Sep '99

11 Sep '99

On 09/10/99 10:09:21 you wrote: >We have a mix of old Ss1s with some Ss2s on a F520 and -- in the >neverending quest for more diskspace -- we may need to replace the Ss1 >with something that holds more. Could a retired Ss1 be hooked up to, say, >a linux box with any old SCSI adapter? Not necessarily doing RAID, just >as a series of 4gb disks. Anyone recycled an old Ss1 in that fashion? Yes. Each disk will appear with a different SCSI ID. Bruce

1 0

local vs. network backup for F740's
by Vance Huntley 10 Sep '99

10 Sep '99

Hi all. We have several F740's with about 400GB each, and we are reexcamining our backup strategy. I would prefer a centralized, network backup over a dedicated backup network. We've heard rumours that the only reasonable way to backup filers is using a locally attached DLT drive, and that we must buy an expensive ($700) NetApp SCSI controller card before we attempt to do a local backup. Does this make sense to you all? What is the conventional wisdom on the ideal way to backup multiple filers? Vance

5 4

attaching a 7-tape stacker
by Dave Toal 10 Sep '99

10 Sep '99

Folks, Hey, all. Another question from the peanut gallery: I recently attached a Sun DLT 4700 (7-tape stacker, one dlt) to a netapp F330. The netapp appears to've recognized the dlt. troi-netapp-fddi> sysconfig -t Tape drive (9b.4) Digital DLT4700 rst0l - rewind device, format is: 42500 bpi 2.6GB nrst0l - no rewind device, format is: 42500 bpi 2.6GB ... I'm trying to set up the tape changer as a Veritas NetBackup storage device, which involves determining what the netapp believes is the robotic device name, controller number, and scsi id of the attached changer. The command syntax is set_ndmp_attr -robot <ndmp server> <robotic device name> <robot controller number> <scsi id of robotic control> <lun of robotic control>. The example given is "set_ndmp_attr -robot toaster spt0 2 3 0". The manual then goes on to say: ----------------------------------------------------------------------------------------- Note: The NetApp file server currently provides no method for determining robotic information. You will have to reference the vendor manuals, check the physical configuration (jumpers and so on), and try different combinations with the set_ndmp_attr command in order to determine the correct information. After each try with the set_ndmp_attr command, use tsdtest and tldtest to check communication with the robot. ----------------------------------------------------------------------------------------- Is this true? Is spt0 a valid netapp robotic device name? Dave troi-netapp-fddi> sysconfig NetApp Release 5.2.1: Thu Dec 31 12:11:38 PST 1998 System ID: 0016782535 (troi-netapp-fddi) slot 0: System Board Memory Size: 192 MB slot 0: SCSI Host Adapter 0 7 Disks: 28.0GB In-Band Enclosure Services slot 0: Ethernet Controller e0 MAC Address: 00:a0:98:00:05:65 (tp-up) slot 2: FDDI Network Adapter f2 MAC Address: 00:00:f8:60:09:c1 (Fiber) slot 4: Dual SCSI Host Adapter SCSI Host Adapter 4a 7 Disks: 28.0GB In-Band Enclosure Services SCSI Host Adapter 4b 7 Disks: 28.0GB In-Band Enclosure Services slot 6: NVRAM Memory Size: 4 MB slot 9: Dual SCSI Host Adapter SCSI Host Adapter 9a 7 Disks: 28.0GB In-Band Enclosure Services SCSI Host Adapter 9b 1 Tape: DLT4700 In-Band Enclosure Services troi-netapp-fddi>

1 0

F330 & ONTAP versions
by Jay Orr 09 Sep '99

09 Sep '99

I was talking with a tech today fixing problems I experienced upgrading our F330 from 4.2a to 5.3.2r1, and I asked if this was the last release for the F330's, since after February you can't purchase a software support for these filers. He said he hadn't heard about the end-of-support on the F330's, but mentioned that 5.4 is scheduled for Feb. My question is, will 5.4 be available for the F330's or is 5.3.2r1 the last release that'll work on the F330s ?? ----------- Fujitsu - Nexion, St. Louis, MO Jay Orr (314) 579-6517

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