toasters

toasters@lists.teaparty.net

13531 discussions

basic configuration, groups, users, quotas
by Charles Bartels 18 Feb '03

18 Feb '03

Hi, I'm setting up a new 810 and seemed to have confused myself mightly. I'm really unclear on what the passwd and group files on the filer are for. Are they just used for quotas? Or are they also used for some sort of authentication which I seem to be missing? We're running a PDC which the filer talks to. Then I have a number of UNIX accounts which will, ultimately, automount their home directories. I would like to set up some group quotas also. In tests, the passwd file on the filer seems irrelevant. -C.

2 1

RE: Checking netapp for bad blocks?
by David Dalby 18 Feb '03

18 Feb '03

Hi Alan & Art, We had a similar problem with a customer and it turned out to be the combination of platform, Oracle version and DOT version. Customer was on RS6000 with AIX 4.3.3 and Oracle 8.0.6 with DOT 6.1. Basically the problem did not appear during intial testing on DOT 5.x. However, in live environment using DOT 6.x they had log curruptions. During testing, NetApp replicated the issue which resolved itself only when going to Oracle 8.1.7. We tried many things, AIX NFS patches, changed Oracle and NetApp parameters without any success ... I suggest you have a chat with NetApp as there are known issues with some version combinations .... FYI the following is an extract of correspondence between NetApp and end-user .... We have two other cases that are very similar to yours in that they involve corrupted Oracle redo logs with AIX. Over the past several weeks, we have created a test environment in our labs with an RS 6000 and AIX 4.3.3.0. We're using an 840 filer with Ontap 6.1. We have a database with all of the files (data, control, online redo logs, and archived redo logs) on the filer. Oracle 7.3.4.5 is installed on the AIX box (I realize that you are running Oracle 8.0.6, but I'll address that later). Our methodology was such that we created the database with just one table and one tablespace. We then launched a script that does millions of inserts. The purpose was to generate a lot of redo activity. With the basic configuration (Oracle 7.3.4.5, Ontap 6.1, and AIX 4.3.3.0), we were able to reproduce the problem that another customer was having with the corrupted redo logs. In an attempt to rectify the problem, we used an iterative technique to try and isolate the cause of the corruption was. We lowered the nfs packet size (rsize and wsize) incrementally from 32k to 16k to 8k to 4k. This prolonged the period of time before the corruption, but did not eliminate it altogether. We changed numerous paramters on the Filer to no avail. We tried udp and tcp. Each time, the script failed with an archival error, which stalled the database. We had to perform a shutdown abort. Upon startup, there were errors reporting corruptions in the online redo logs, which is very similar to your case. We've had conference calls with Oracle and IBM. Oracle dismissed this problem, because the corruption does not occur with both sets of redo logs on local disk. IBM, however, has acknowledged this is a problem.They are having development engineers analyze the AIX trace file we provided. IBM also told us that just last week they had released two new NFS-related patches for AIX. We have received these patches and applied them to our test system. Currently, we are running our tests with the most recent AIX-NFS specifc patches installed. We will also be conducting similiar tests with Oracle 8. Most likely, this will be 8.1.7. Hope it helps Dave The latest results from our testing hold some promise. Using Oracle > 8.1.7 with online and archived redo logs on the filer, we ran our load > test for 17 hours with no corruptions. We will be continuing this test > for the next two weeks to make sure that 8.1.7 is a viable solution. We > have a TAR open with Oracle that we hope will identify the root cause of > the problem. In parallel to the ongoing 8.1.7 test, we will be conducting > 8.0.5 and 8.0.6 tests on separate equipment > -----Original Message----- > From: Art Hebert [mailto:art@arzoon.com] > Sent: Friday, 14 February 2003 3:01 PM > To: 'Alan McLachlan'; Art Hebert > Cc: toasters(a)mathworks.com > Subject: RE: Checking netapp for bad blocks? > > > > > Alan -- the f760 is clustered redo logs on both filers and > archive logs on > the second filer. The primary db is fine. But the archive > logs are getting > corrupted someplace over on the standby database. Like you > say its one of > the checks we are looking at. > > art > > > -----Original Message----- > From: Alan McLachlan [mailto:amclachlan@asi.com.au] > Sent: Thursday, February 13, 2003 10:18 PM > To: Art Hebert > Cc: toasters(a)mathworks.com > Subject: RE: Checking netapp for bad blocks? > > > You can run wack (I think it's "wafl_check" now, look at the list) in > maintenance mode from the floppy boot menu ("ctrl-c" on a > disk reboot from a > serial console). > > However, unless your NVRAM card has failed - which you would > know about > instantly - the likelyhood that this will do you any good at > all is remote > in the extreme. Your DBA doesn't understand the > always-consistent fs on > NetApp (WAFL) so he's trying to put a tick in a box on his > troubleshooting > checklist. > > It is far more likely that what he has is application-level corruption > within the files, which fsck on a UFS volume wouldn't have > helped him with > anyway. > > Are the transaction logs on the filer or on local disk on the database > server? > > > > -----Original Message----- > From: Art Hebert [mailto:art@arzoon.com] > Sent: Friday, 14 February 2003 3:41 AM > To: 'Toasters(a)Mathworks.Com' > Subject: Checking netapp for bad blocks? > > > > Our oracle database has experienced two problems lately with file > corruption on our standby database. The corruption isn't on > the primary > database and our Oracle DBA is asking if I can do something > similar to fsck > on the netapp. > > Any thoughts on the commands to run and what to check for would be > appreciated. > > art > > -----Original Message----- > From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] > Sent: Thursday, February 13, 2003 5:49 AM > To: Jonathan > Cc: Jordan Share; 'Toasters(a)Mathworks.Com' > Subject: Re: Adding a drive shelf to my existing F740 > > > Jonathan wrote: > > >>2 - there is an extra trick to save a spare disk : don't > keep two but > >>only one spare disks : a 36G one, as Filer can reconstruct > a 18G broken > >>disk on a 36G. BUT you have to order Netapp for a 36G after that > >>failure. If you have a hardware contract with Netapp, take care > >>because, when a 18G fail, they would send you a 18G too, > not a 36G. You > >>would have to check for that (look for a special deal ?) > >> > > > >To add to your trick #2, Don't worry about getting a 18GB > back from Netapp > >and leaving your 36 acting like a 18. Simply add the 18 in > the place of the > >failed 18 and let the filer take it as a spare. Then do a > disk fail on the > >36 acting as a 18. The filer will now look for a spare 18 > and find the new > >spare to rebuild the raid group. Then do a disk unfail on > the 36 acting as > a > >18 and Ontap will zero the 36 and put it back as a 36 spare. > So you don't > >need to work out a special deal with Netapp. I have done > this many times > and > >with great success. > > > > > of course ! i knew it indeed, what a dumb I am :) > you have to switch mode in order to use disk unfail : use " > rc_toggle_basic " or " priv set advanced / admin" > > > > >----- Original Message ----- > >From: "Stephane Bentebba" <stephane.bentebba(a)fps.fr> > >To: "Jordan Share" <iso9(a)jwiz.org> > >Cc: "'Toasters(a)Mathworks.Com'" <toasters(a)mathworks.com> > >Sent: Thursday, February 13, 2003 6:12 AM > >Subject: Re: Adding a drive shelf to my existing F740 > > > > > > > > > >>First : to be sure we speak the same language (I'm french) > >>the raidsize include the parity disk. > >>a group raid of sized 14 can contain up to 13 data disks > and one parity > >>disk. > >>the max size of a raid can be 28 > >> > >>- the more disk in a raid you have, the more the filer need time to > >>reconstruct the disk (and the longer the CPU is used for that). > >>- larger the disk is, the more it consume time also. > >>for exemple, a F760 with a cpu load average at 40% in > production can go > >>up to 50% during 6 hours to reconstruct a 72G disk > >> > >>1 - taking this into account, I won't advise you to move > your raidsize > >>to 28, but if you want to save as many as possible disk, > you can turn > >>the raidsize to 28 and add those 36G disks in the same > raidgroup than > >>other (18G) > >>2 - there is an extra trick to save a spare disk : don't > keep two but > >>only one spare disks : a 36G one, as Filer can reconstruct > a 18G broken > >>disk on a 36G. BUT you have to order Netapp for a 36G after that > >>failure. If you have a hardware contract with Netapp, take care > >>because, when a 18G fail, they would send you a 18G too, > not a 36G. You > >>would have to check for that (look for a special deal ?) > >> > >>These two tricks apart, I can't see better ways than what > you had plained > >> > >>Jordan Share wrote: > >> > >> > >> > >>>After reading further in my manuals, I've got some > questions about the > >>>RAIDgroup size. > >>> > >>>When I initially created the volume, I made the raidsize > 14, so that it > >>>would use 1 parity disk for the 14 disks we had at that time. > >>> > >>>Looking at it now, I kind of think that I want a raidsize > of 13 for the > >>>current volume (since one disk is a hot spare). > >>> > >>>So, I issued: > >>>vol options vol0 raidsize 13 > >>> > >>>That worked ok, because now: > >>> > >>> > >>> > >>> > >>>>vol status vol0 > >>>> > >>>> > >>>> > >>>> > >>> Volume State Status Options > >>> vol0 online normal root, raidsize=13 > >>> raid group 0: normal > >>> > >>>Basically, what I'm trying to avoid here is having the > first 36gig disk > >>>added to the initial raidgroup. I believe changing the > raidsize to 13 > >>> > >>> > >will > > > > > >>>have fixed that, since now that raidgroup is full, and > additional disks > >>> > >>> > >will > > > > > >>>go into their own raidgroup. > >>> > >>>I welcome (and request. :) all comments on this post. > >>> > >>>Thanks very much, > >>>Jordan Share > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: owner-toasters(a)mathworks.com > >>>>[mailto:owner-toasters@mathworks.com]On Behalf Of > devnull(a)adc.idt.com > >>>>Sent: Wednesday, February 12, 2003 11:28 AM > >>>>To: Jordan Share > >>>>Cc: 'Toasters(a)Mathworks.Com' > >>>>Subject: Re: Adding a drive shelf to my existing F740 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>As I understand it, I would then have 2 hot spares (18 > and 36), and two > >>>>>drives for parity. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Yup. > >>>> > >>>>You would need the separate spare to accomodate the > difference in drive > >>>>sizes. The parity drive is a function of RAID 4. > >>>> > >>>>We did the same about a year back on our 740 and it worked well. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Are there any "gotchas" (or blatant ignorance on my part) in > >>>>> > >>>>> > >>>>> > >>>>> > >>>>this scenario? > >>>>It was mostly smooth. Though you might need to upgrade your ONTAP > >>>> > >>>> > >version > > > > > >>>>to 6.1.1R2 atleast > >>>> > >>>> > >>>> > >>>>/dev/null > >>>> > >>>>devnull(a)adc.idt.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > > > **** ASI Solutions Disclaimer **** > The material transmitted may contain confidential and/or privileged > material and is intended only for the addressee. If you > receive this in > error, please notify the sender and destroy any copies of the material > immediately. ASI will protect your Privacy according to the 10 Privacy > Principles outlined under the new Privacy Act, Dec 2001. > > This email is also subject to copyright. Any use of or > reliance upon this > material by persons or entities other than the addressee is > prohibited. > > E-mails may be interfered with, may contain computer viruses or other > defects. Under no circumstances do we accept liability for > any loss or > damage which may result from your receipt of this message or any > attachments. > **** END OF MESSAGE **** > **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

1 0

Using R100 as failover
by Karsten Thygesen 17 Feb '03

17 Feb '03

Hi We are (yet) a small NetApp shop with a single 1Tb 810 solution. And we are pretty happy with it :-) Now, we have yet to establish backup and we have a pretty huge SAN (160Tb+) as well as a number (600+) unix servers we need to backup. For that, we use Networker with tape silos, and that works just fine. For the NAS, we are now considering to either hook it into our existing networker infrastructure or to push in a R100 between. The R100 should then work as near-storage for san to provide a more flexible solution as well a faster restore times. The R100 will also work as backup server for a number of FreeBSD servers as well as a bunsh of servers, where Legato is not supported or not an option. So far so good, but why stop here? So my question is, that can I use the R100 as a cold/hot standby and let it take over the job of the F810, if that should break hard some day? I understand, that I can not use it in a cluster setup, as the performance is rather different, but could it take over the IP adresses of the F810, export the same qtrees and just work, but of cause with reduced performance? What is the required licenses to actually build this setup? And how close a mirror can I make it? Realtime? Sorry if this is a basic question, but as I said, we are pretty new in the NetApp direction... best regards, Karsten

2 1

RE: Data ONTAP Upgrade
by Hill, Aaron 16 Feb '03

16 Feb '03

Hey there, I welcome questions. Unfortunately, my answers may not be sufficient to satisfy your mental hunger. To be honest, I don't know exactly what the D8 does. I was informed that it fixes the snapmirror code. The error was found to occur only in our "specific" circumstance. So what was/is our circumstance? 1) F880 source snapmirroring 3 batch area volumes to an F820 target across a 20Mbit Ethernet WAN. 2) The amount of data change per day is high. Approximately 10-40Gb per volume. 3) We were experiencing poor throughput across the WAN link (carrier issue) and had to frequently abort the snapmirror and delete snapshots from the F880 source in order to prevent snapshot space over-running production data space. This throughput has since been addressed (before D8). 4) The F820 target panicked a couple of times and dumped to the ok prompt. One of the target volumes was found to be corrupt. It was difficult to say if the source filer caused it or the target filer developed the corruption independently. We had some cases open and ran wafl checks and scans on both filers as a result. No errors were turned up. 5) The crash dump file was ftp'd to NetApp. This lead to the 6.3.1D8 debug release. When I get some more time, I might read into it a bit further. For now, I am more than happy that they have addressed the issue and fixed it very quickly. We have not had any problems with 6.3.1 or the D8 releases. Thanks, Aaron -----Original Message----- From: Chris Blackmor [mailto:chris.blackmor@amd.com] Sent: Sunday, February 16, 2003 6:48 AM To: Hill, Aaron Cc: 'Paul McGuinness (ext. 771)'; 'toasters(a)mathworks.com' Subject: Re: Data ONTAP Upgrade What does the D8 fix for snapmirror? Inquiring minds want to know. ;) C- On Fri, Feb 14, 2003 at 07:18:19PM -0600, Hill, Aaron wrote: > We are running 6.3.1 on one filer (F880) and 6.3.1D8 (debug release for a > snapmirror problem we were having) on another (F820). 2 others still running > 6.2.2 I believe. > > As far as I know, all new F960s being shipped have 6.3.1 on them. > > So overall, I have to say I recommend it. If you are snapmirroring, make > sure you put 6.3.1D8 on your destination filer, that is the advice from our > NetApp representative. > > Thanks, > Aaron Hill > Systems Engineer > www.navitaire.com > > > -----Original Message----- > From: Paul McGuinness (ext. 771) [mailto:Paul.McGuinness@fineos.com] > Sent: Saturday, February 15, 2003 2:58 AM > To: 'toasters(a)mathworks.com' > Subject: Data ONTAP Upgrade > > Hi, > I have a F720 currently running on Data ONTAP 6.1.2R2 and everything is > running fine. > My question is to those of you 6.6.2 (the current GA release) and those of > you on 6.3.1. > > I was going to upgrade to 6.2.2, just to keep my system up to date, but > according to the NOW site there are a good few more active systems running > 6.3.1. > > Would 6.3.1 be a better upgrade to go to? I also see that there is now a 6.4 > first customer shipment release (12th Feb) but I think I'll leave that for > those of you who have filers to play with.... > :o) > > So 6.6.2 or 6.3.1? > > > > > > ************************************************************************** > The information contained in this e-mail is confidential, > may be privileged and is intended only for the use of the > recipient named above. If you are not the intended > recipient or a representative of the intended recipient, > you have received this e-mail in error and must not copy, > use or disclose the contents of this email to anybody > else. If you have received this e-mail in error, please > notify the sender immediately by return e-mail and > permanently delete the copy you received. This email has > been swept for computer viruses. However, you should > carry out your own virus checks. > > > Registered in Ireland, No. 205721. http://www.FINEOS.com > ************************************************************************** -- -------------------------------------------------------------------- * Chris Blackmor _______ | * * Advanced Micro Devices \____ | | Toto... I've * * Phone: (512) 602-1608 /| | | | a feeling we're * * Fax: (512) 602-5155 | |___| | | not in Kansas * * Email: chris.blackmor(a)amd.com |____/ \| | anymore. * -------------------------------------------------------------------- * My comments are mine, and mine alone. * --------------------------------------------------------------------

1 0

RE: using vol0 / consolidation
by Alan McLachlan 16 Feb '03

16 Feb '03

Stephane, Apologies for misnaming you in my last post... **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

1 0

Netapp clustering and NFS failover
by herb kornfeldt 16 Feb '03

16 Feb '03

I'm evaluating NFS server appliances to be used by a couple of dozen clients (currently all solaris, but possibly linux and hpux in future) all running a distributed application. We're looking at how clusters handle failing over NFS serving from one netapp to another. From the research we've done on netapp and other vendors, it looks like it takes about 20 seconds for the nfs server daemon to come back, but the thing that kills many vendors is that client lock recovery is slow and/or buggy. The lockd grace period is tunable down from 45s on most servers, but that still means you are down for 65seconds, and that's pretty painful. And that's assuming that the server implementation is clever enough to correctly transfer knowledge about locks from the dead node to the active server node, something which we have seen not to happen on at least one major vendor's implementation. Has anyone share their experiences of failing over clustered netapps for nfs? What kind of failover times do you see (including lock recovery)? Does anything not work properly? tia --herb _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

RE: Data ONTAP Upgrade
by Hill, Aaron 15 Feb '03

15 Feb '03

We are running 6.3.1 on one filer (F880) and 6.3.1D8 (debug release for a snapmirror problem we were having) on another (F820). 2 others still running 6.2.2 I believe. As far as I know, all new F960s being shipped have 6.3.1 on them. So overall, I have to say I recommend it. If you are snapmirroring, make sure you put 6.3.1D8 on your destination filer, that is the advice from our NetApp representative. Thanks, Aaron Hill Systems Engineer www.navitaire.com -----Original Message----- From: Paul McGuinness (ext. 771) [mailto:Paul.McGuinness@fineos.com] Sent: Saturday, February 15, 2003 2:58 AM To: 'toasters(a)mathworks.com' Subject: Data ONTAP Upgrade Hi, I have a F720 currently running on Data ONTAP 6.1.2R2 and everything is running fine. My question is to those of you 6.6.2 (the current GA release) and those of you on 6.3.1. I was going to upgrade to 6.2.2, just to keep my system up to date, but according to the NOW site there are a good few more active systems running 6.3.1. Would 6.3.1 be a better upgrade to go to? I also see that there is now a 6.4 first customer shipment release (12th Feb) but I think I'll leave that for those of you who have filers to play with.... :o) So 6.6.2 or 6.3.1? ************************************************************************** The information contained in this e-mail is confidential, may be privileged and is intended only for the use of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this email to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This email has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com **************************************************************************

2 1

RE: wafl scan reallocate not improving layout?
by jwitham＠takedapharm.com 14 Feb '03

14 Feb '03

Hi Art: What kind of data is contained on the vol? Is it one huge file (DB) or a bajillion little ones? Have you thought about trying the reallocate when things are quiet? (no users or db offline) -john -----Original Message----- From: Art Hebert [mailto:art@arzoon.com] Sent: Thursday, February 13, 2003 5:42 PM To: 'jwitham(a)takedapharm.com'; Ambrose_Earle(a)shamrockfoods.com; toasters(a)mathworks.com Subject: wafl scan reallocate not improving layout? I have a volume that shows a layout of 5 when doing a wafl scan measure layout. I have tried reallocating it but it never gets below 5. Using statit the data seems to be laid out evenly, 4.2 is the parity disk. disk ut% xfers ureads--chain-usecs writes--chain-usecs cpreads-chain-usecs /vol/vol0 group 0: 4.2 3 4.22 0.43 1.00 23079 2.72 3.80 2986847599971 1.06 2.46 2182 4.4 39 79.56 77.18 1.91 2574 1.33 4.46 3793820692012 1.04 2.40 2365 4.1 37 76.72 74.81 1.91 2553 0.93 5.28 3193299281907 0.97 3.02 1613 4.6 41 83.67 81.56 1.88 2624 1.35 4.72 2462422822812 0.76 2.51 2198 4.0 40 83.62 81.77 1.87 2562 1.03 5.83 2711737467108 0.82 2.61 1959 4.3 40 83.70 81.83 1.86 2594 1.06 5.74 2738534194560 0.81 2.47 2055 4.5 40 84.04 82.17 1.86 2579 1.07 5.72 2611584689054 0.80 2.50 2099 Should I cease activity to the filer and run the wafl reallocate then? Thoughts and thanks art -----Original Message----- From: jwitham(a)takedapharm.com [mailto:jwitham@takedapharm.com] Sent: Tuesday, January 28, 2003 10:39 AM To: Ambrose_Earle(a)shamrockfoods.com; toasters(a)mathworks.com Subject: RE: wafl scan We use 'wafl scan reallocate' weekly to reorder our Exchange 5.5 databases. They keep growing, and are over 100GB apiece. The wafl scan reallocate helps our use of SnapManager verifications greatly. We have been known to run it in the middle of the day, but with a big performance hit (as you have seen). Haven't tried it in conjunction with SnapMirror. Just for grins, we also use 'wafl scan measure_layout' before and after the reallocate to ensure that we've accomplished something. We affectionately refer to the process as 'reshuffling the wafl house'. HTH, -john -----Original Message----- From: Ambrose_Earle(a)shamrockfoods.com [mailto:Ambrose_Earle@shamrockfoods.com <mailto:Ambrose_Earle@shamrockfoods.com> ] Sent: Thursday, January 23, 2003 7:28 PM To: toasters(a)mathworks.com Subject: wafl scan Does anyone have any (good) experience with the wafl scan commands? I am testing Snapmirror and used it to mirror 7x34's to 10x34's. Of course, the data was only written to the first seven drives, so I used 'wafl scan reallocate <volume>' and it seemed to improve the layout quite dramatically. Is this a good use of the command? Other than affecting performance, I'm assuming everything is accessible during the run of this command? Thanks in advance, This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

1 0

OS/2 on NetApp
by Jeff Burton 14 Feb '03

14 Feb '03

Is anyone accessing data on a NetApp from an OS/2 client using CIFS? I have heard of people using NFS and it works fine, but because of some extensions OS/2 adds to the CIFS protocol, NetApp does not support OS/2 CIFS clients. While NFS is an option, this will be difficult to implement because we would need to create unix type accounts for all the OS/2 users to map their AD accounts to. I am running 6.2.1R2 and am about to test with the newer versions of ONTAP. Thanks, ______________________________________________________________ Jeff Burton Storage Architect Abbott Laboratories EMAIL: Jeffrey.Burton(a)Abbott.com Dept. GB16/Bldg. AP9A-LL PHONE: 847-935-5778 100 Abbott Park Rd. FAX: 847-935-0142 Abbott Park, IL 60064-6115

1 0

Data ONTAP Upgrade
by Paul McGuinness (ext. 771) 14 Feb '03

14 Feb '03

Hi, I have a F720 currently running on Data ONTAP 6.1.2R2 and everything is running fine. My question is to those of you 6.6.2 (the current GA release) and those of you on 6.3.1. I was going to upgrade to 6.2.2, just to keep my system up to date, but according to the NOW site there are a good few more active systems running 6.3.1. Would 6.3.1 be a better upgrade to go to? I also see that there is now a 6.4 first customer shipment release (12th Feb) but I think I'll leave that for those of you who have filers to play with.... :o) So 6.6.2 or 6.3.1? ************************************************************************** The information contained in this e-mail is confidential, may be privileged and is intended only for the use of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this email to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This email has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com **************************************************************************

1 0

RE: XP refreshing
by Bui, Marcus 14 Feb '03

14 Feb '03

Matt, Microsoft has identify this to be a problem with the XP client. A hotfix is available but I you need to request it from MS support. The patch will be roll up into the next XP service pack (3). More details here: http://support.microsoft.com/default.aspx?scid=kb;en-us;330929 I applied the hotfix and the Registry changes and it does resolve the 'refresh' problem. Hope this helps. Cheers, Marcus Bui -----Original Message----- From: Matt Miller [mailto:m.miller@duke.edu] Sent: Tuesday, February 04, 2003 2:58 PM To: Bui, Marcus Cc: 'toasters(a)mathworks.com' Subject: Re: XP refreshing sorry for the delay, we have ~300 XP machines which map the same share. matt "Bui, Marcus" wrote: > Matt, > > How many XP clients are using the filer? Or connecting to the same > share? Does the filer experience any performance issue? > > thanks, > Marcus > > -----Original Message----- > From: Matt Miller [mailto:m.miller@duke.edu] > Sent: Thursday, January 09, 2003 9:40 AM > To: Bui, Marcus; 'toasters(a)mathworks.com' > Subject: Re: XP refreshing > > Let me take that back... the refresh does happen, but at our site it > is only every 20 seconds. > > matt > > Matt Miller wrote: > > > We have XP clients in a mixed mode AD environment with an F820 > > running DOT > 6.3. > > > > I do not see the refresh traffic you refer to below; however, every > > time > you > > move the mouse in the active explorer window, explorer asks the > > filer for summary information for the directory/file. When I leave > > the mouse still, > no > > traffic is seen. Is this what you are experiencing? > > > > matt > > > > "Bui, Marcus" wrote: > > > > > Hello Toasters, > > > > > > I have an F740c running 6.1.2R1 in NT4 domain. Currently, the > > > client PC > are > > > being migrated to XP into W2K AD (mixed mode). Came across a > > > peculiar problem and wondering if anyone else experience it. > > > > > > XP client with Windows Explorer open is continually refreshing > > > when open against a Filer volume, share folder. Analysis has > > > shown that it seems to be every two seconds a refresh > > > occurs, and when using a network trace tool, it seems to average out at > > > around 50K per second. As soon as explorer's focus is placed elsewhere, > or > > > shut down, this network load stops. This 'refreshing' only > > > appears if > the > > > share folder is highly utilize. Connecting to a share folder that > > > is no busy, the 'refreshing' does not exist. Notice this with W2K > > > Pro client > as > > > well, but not as frequent as XP Client. > > > > > > thanks, > > > > > > Marcus Bui > > > > -- > > Matt Miller > > IT Infrastructure Team > > Duke University - Fuqua School of Business > > -- > Matt Miller > IT Infrastructure Team > Duke University - Fuqua School of Business -- Matt Miller IT Infrastructure Team Duke University - Fuqua School of Business

1 0

sanity check, 2 ndmpd sessions @ once?
by Toal, Dave 14 Feb '03

14 Feb '03

Noticed this on a 740 that's only got 1 DLT. Veritas netbackup is scheduling bkp jobs with ndmp, from a sun box. There've been some odd failures where the tape fails to unload after the bkp, recently. ndmpd status doesn't show any sessions active when that happens though. Right now I'm seeing 2 ndmp sessions; I don't recall that before, and I'm wondering if this means netbackup is having problems. The ip addr is the sun box running nb, for both sessions; there's a bkp running while I'm looking at this. 6.1.3R2 statler> ndmpd status ndmpd ON. Session: 47 Active version: 2 Operating on behalf of primary host. tape device: nrst0a mover state: Idle data state: Idle data operation: None Session: 36 Active version: 2 Operating on behalf of primary host. tape device: not open mover state: Paused data state: Active data operation: Backup statler> sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 8% 16 0 0 465 10 0 27 0 442 >60 7% 38 0 0 466 47 35 0 0 438 >60 statler> ndmpd probe 47 ndmpd ON. Session: 47 isActive: TRUE protocol version: 2 effHost: Local authorized: TRUE client addr: 206.229.36.82:52341 spt.device_id: none spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.device: nrst0a tape.mode: Read/Write mover.state: Idle mover.mode: Read mover.pauseReason N/A mover.haltReason N/A mover.recordSize: 0 mover.recordNum: 0 mover.dataWritten: 0 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: -1 mover.windowLength: -1 mover.position: 0 mover.connect.addr_type:LOCAL data.operation: None data.state: Idle data.haltReason: N/A data.connect.addr_type: LOCAL data.bytesProcessed: 0 statler> ndmpd probe 36 ndmpd ON. Session: 36 isActive: TRUE protocol version: 2 effHost: Local authorized: TRUE client addr: 206.229.36.82:51967 spt.device_id: none spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.device: not open tape.mode: Read only mover.state: Paused mover.mode: Read mover.pauseReason EOM mover.haltReason N/A mover.recordSize: 64512 mover.recordNum: 242736 mover.dataWritten: 15659384832 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: -1 mover.windowLength: -1 mover.position: 0 mover.connect.addr_type:LOCAL data.operation: Backup data.state: Active data.haltReason: N/A data.connect.addr_type: LOCAL data.bytesProcessed: 15659709440 statler> bash-2.03# bpps -a | grep stat root 3281 1 0 17:03:55 ? 12:39 bptm -w -pid 3273 -c statler -den 13 -rt 8 -rn 0 -stunit statler-dlt -cl statle root 3273 1 0 17:03:54 ? 0:00 bpbrm -backup -mt 3 -to 0 -S netback -c statler -hostname statler -ru root -cl bash-2.03# -- Dave Toal Systems Architect Thomson & Thomson N. Quincy, MA

2 1

RE: using vol0
by Clawson, Simon 14 Feb '03

14 Feb '03

The only benefit as I see it to having the smallest possible vol0 is recovery time. You can back up and recover the small amount of data in a few minutes on most tape devices, meaning you are up and running fairly quickly in the event of losing the volume. However, there are methods of replicating the /etc data to another volume, then telling the filer to boot this as vol0. This would of course mean any NIS maps etc are broken until you change their paths, but the filer would be up and running quicker than if you were to have to restore the whole root volume first, and you would not be using two 72Gb disks for 40mb of data. -----Original Message----- From: Alan McLachlan [mailto:amclachlan@asi.com.au] Sent: 13 February 2003 01:29 To: Charles Bartels; toasters(a)mathworks.com Subject: RE: using vol0 Hi Charles, Don't understand why you're asking this. In most cases that I'm aware of vol0 is used for data. In some cluster scenarious, particularly with local or remote syncmirror, it becomes necessary to burn two disks to have a root volume that's just for the filer's config files - usually only on one half of the cluster. I can't imagine apart from that why someone would want to consume two whole drives for the 40MB or so of data in the /etc directory. In fact, many of my customers have only configured a second volume in order to support a database. User home directories and workgroup data stay on vol0. You should of course make use of qutoa'd qtrees within vol0 extensively to prevent it filling up - theoretically this could cause a panic in some circumstances although Data OnTap is much more robust than a Unix or Linux in this regard. ---------------------------------------------------------------------------- --------------------------- On a related note, one issue that crops up from time to time is that when a filer is used to replace a bunch of Windows fileservers on a large CIFS network, it can happen that well-meaning Domain Admins that don't directly look after the filer and aren't trained in Data OnTAP may accidently corrupt config files in the /etc directory. It would be nice to restrict access to just a select group of trained admins. Using a Windows domain group is not the answer, as any Domain Admin can take ownership of the resource. A solution is to turn the /etc directory into a unix security style qtree: * make a new qtree called say "etcnew" * copy the files from /etc to /etcnew * rename /etc to "etcold" * rename /etcnew to "etc" * set the security style of etc to unix This works even if you only have a CIFS licence. You should then install ssaccess on a workstation to manage the security on the /etc qtree. Then, in the usermap.cfg file in /etc put an entry for each trusted admin like so: *\root => nobody (security defensive entry) DOMAIN\fred => root DOMAIN\wilma => root As the final step, set options wafl.nt_admin_priv_map_to_root to OFF. The result is that, in the example above, only the domain users "fred" and "wilma" can make changes to the /etc directory. For all the other resources on the filer (which have NTFS security style), normal domain security rules apply. -----Original Message----- From: Charles Bartels [mailto:cbartels@openharbor.com] Sent: Wednesday, 12 February 2003 3:45 AM To: toasters(a)mathworks.com Subject: using vol0 Hi, I'm configuring an F810 and space is going to be a little tight. How do people feel about adding disks to vol0 and using that instead of creating a whole separate volume (and burning a another parity disk) ? -Charles Bartels **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

3 2

RE: Checking netapp for bad blocks?
by Art Hebert 14 Feb '03

14 Feb '03

Alan -- the f760 is clustered redo logs on both filers and archive logs on the second filer. The primary db is fine. But the archive logs are getting corrupted someplace over on the standby database. Like you say its one of the checks we are looking at. art -----Original Message----- From: Alan McLachlan [mailto:amclachlan@asi.com.au] Sent: Thursday, February 13, 2003 10:18 PM To: Art Hebert Cc: toasters(a)mathworks.com Subject: RE: Checking netapp for bad blocks? You can run wack (I think it's "wafl_check" now, look at the list) in maintenance mode from the floppy boot menu ("ctrl-c" on a disk reboot from a serial console). However, unless your NVRAM card has failed - which you would know about instantly - the likelyhood that this will do you any good at all is remote in the extreme. Your DBA doesn't understand the always-consistent fs on NetApp (WAFL) so he's trying to put a tick in a box on his troubleshooting checklist. It is far more likely that what he has is application-level corruption within the files, which fsck on a UFS volume wouldn't have helped him with anyway. Are the transaction logs on the filer or on local disk on the database server? -----Original Message----- From: Art Hebert [mailto:art@arzoon.com] Sent: Friday, 14 February 2003 3:41 AM To: 'Toasters(a)Mathworks.Com' Subject: Checking netapp for bad blocks? Our oracle database has experienced two problems lately with file corruption on our standby database. The corruption isn't on the primary database and our Oracle DBA is asking if I can do something similar to fsck on the netapp. Any thoughts on the commands to run and what to check for would be appreciated. art -----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: Thursday, February 13, 2003 5:49 AM To: Jonathan Cc: Jordan Share; 'Toasters(a)Mathworks.Com' Subject: Re: Adding a drive shelf to my existing F740 Jonathan wrote: >>2 - there is an extra trick to save a spare disk : don't keep two but >>only one spare disks : a 36G one, as Filer can reconstruct a 18G broken >>disk on a 36G. BUT you have to order Netapp for a 36G after that >>failure. If you have a hardware contract with Netapp, take care >>because, when a 18G fail, they would send you a 18G too, not a 36G. You >>would have to check for that (look for a special deal ?) >> > >To add to your trick #2, Don't worry about getting a 18GB back from Netapp >and leaving your 36 acting like a 18. Simply add the 18 in the place of the >failed 18 and let the filer take it as a spare. Then do a disk fail on the >36 acting as a 18. The filer will now look for a spare 18 and find the new >spare to rebuild the raid group. Then do a disk unfail on the 36 acting as a >18 and Ontap will zero the 36 and put it back as a 36 spare. So you don't >need to work out a special deal with Netapp. I have done this many times and >with great success. > > of course ! i knew it indeed, what a dumb I am :) you have to switch mode in order to use disk unfail : use " rc_toggle_basic " or " priv set advanced / admin" > >----- Original Message ----- >From: "Stephane Bentebba" <stephane.bentebba(a)fps.fr> >To: "Jordan Share" <iso9(a)jwiz.org> >Cc: "'Toasters(a)Mathworks.Com'" <toasters(a)mathworks.com> >Sent: Thursday, February 13, 2003 6:12 AM >Subject: Re: Adding a drive shelf to my existing F740 > > > > >>First : to be sure we speak the same language (I'm french) >>the raidsize include the parity disk. >>a group raid of sized 14 can contain up to 13 data disks and one parity >>disk. >>the max size of a raid can be 28 >> >>- the more disk in a raid you have, the more the filer need time to >>reconstruct the disk (and the longer the CPU is used for that). >>- larger the disk is, the more it consume time also. >>for exemple, a F760 with a cpu load average at 40% in production can go >>up to 50% during 6 hours to reconstruct a 72G disk >> >>1 - taking this into account, I won't advise you to move your raidsize >>to 28, but if you want to save as many as possible disk, you can turn >>the raidsize to 28 and add those 36G disks in the same raidgroup than >>other (18G) >>2 - there is an extra trick to save a spare disk : don't keep two but >>only one spare disks : a 36G one, as Filer can reconstruct a 18G broken >>disk on a 36G. BUT you have to order Netapp for a 36G after that >>failure. If you have a hardware contract with Netapp, take care >>because, when a 18G fail, they would send you a 18G too, not a 36G. You >>would have to check for that (look for a special deal ?) >> >>These two tricks apart, I can't see better ways than what you had plained >> >>Jordan Share wrote: >> >> >> >>>After reading further in my manuals, I've got some questions about the >>>RAIDgroup size. >>> >>>When I initially created the volume, I made the raidsize 14, so that it >>>would use 1 parity disk for the 14 disks we had at that time. >>> >>>Looking at it now, I kind of think that I want a raidsize of 13 for the >>>current volume (since one disk is a hot spare). >>> >>>So, I issued: >>>vol options vol0 raidsize 13 >>> >>>That worked ok, because now: >>> >>> >>> >>> >>>>vol status vol0 >>>> >>>> >>>> >>>> >>> Volume State Status Options >>> vol0 online normal root, raidsize=13 >>> raid group 0: normal >>> >>>Basically, what I'm trying to avoid here is having the first 36gig disk >>>added to the initial raidgroup. I believe changing the raidsize to 13 >>> >>> >will > > >>>have fixed that, since now that raidgroup is full, and additional disks >>> >>> >will > > >>>go into their own raidgroup. >>> >>>I welcome (and request. :) all comments on this post. >>> >>>Thanks very much, >>>Jordan Share >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: owner-toasters(a)mathworks.com >>>>[mailto:owner-toasters@mathworks.com]On Behalf Of devnull(a)adc.idt.com >>>>Sent: Wednesday, February 12, 2003 11:28 AM >>>>To: Jordan Share >>>>Cc: 'Toasters(a)Mathworks.Com' >>>>Subject: Re: Adding a drive shelf to my existing F740 >>>> >>>> >>>> >>>> >>>> >>>> >>>>>As I understand it, I would then have 2 hot spares (18 and 36), and two >>>>>drives for parity. >>>>> >>>>> >>>>> >>>>> >>>>Yup. >>>> >>>>You would need the separate spare to accomodate the difference in drive >>>>sizes. The parity drive is a function of RAID 4. >>>> >>>>We did the same about a year back on our 740 and it worked well. >>>> >>>> >>>> >>>> >>>> >>>>>Are there any "gotchas" (or blatant ignorance on my part) in >>>>> >>>>> >>>>> >>>>> >>>>this scenario? >>>>It was mostly smooth. Though you might need to upgrade your ONTAP >>>> >>>> >version > > >>>>to 6.1.1R2 atleast >>>> >>>> >>>> >>>>/dev/null >>>> >>>>devnull(a)adc.idt.com >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> > > > > **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

1 0

RE: Checking netapp for bad blocks?
by Alan McLachlan 14 Feb '03

14 Feb '03

You can run wack (I think it's "wafl_check" now, look at the list) in maintenance mode from the floppy boot menu ("ctrl-c" on a disk reboot from a serial console). However, unless your NVRAM card has failed - which you would know about instantly - the likelyhood that this will do you any good at all is remote in the extreme. Your DBA doesn't understand the always-consistent fs on NetApp (WAFL) so he's trying to put a tick in a box on his troubleshooting checklist. It is far more likely that what he has is application-level corruption within the files, which fsck on a UFS volume wouldn't have helped him with anyway. Are the transaction logs on the filer or on local disk on the database server? -----Original Message----- From: Art Hebert [mailto:art@arzoon.com] Sent: Friday, 14 February 2003 3:41 AM To: 'Toasters(a)Mathworks.Com' Subject: Checking netapp for bad blocks? Our oracle database has experienced two problems lately with file corruption on our standby database. The corruption isn't on the primary database and our Oracle DBA is asking if I can do something similar to fsck on the netapp. Any thoughts on the commands to run and what to check for would be appreciated. art -----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: Thursday, February 13, 2003 5:49 AM To: Jonathan Cc: Jordan Share; 'Toasters(a)Mathworks.Com' Subject: Re: Adding a drive shelf to my existing F740 Jonathan wrote: >>2 - there is an extra trick to save a spare disk : don't keep two but >>only one spare disks : a 36G one, as Filer can reconstruct a 18G broken >>disk on a 36G. BUT you have to order Netapp for a 36G after that >>failure. If you have a hardware contract with Netapp, take care >>because, when a 18G fail, they would send you a 18G too, not a 36G. You >>would have to check for that (look for a special deal ?) >> > >To add to your trick #2, Don't worry about getting a 18GB back from Netapp >and leaving your 36 acting like a 18. Simply add the 18 in the place of the >failed 18 and let the filer take it as a spare. Then do a disk fail on the >36 acting as a 18. The filer will now look for a spare 18 and find the new >spare to rebuild the raid group. Then do a disk unfail on the 36 acting as a >18 and Ontap will zero the 36 and put it back as a 36 spare. So you don't >need to work out a special deal with Netapp. I have done this many times and >with great success. > > of course ! i knew it indeed, what a dumb I am :) you have to switch mode in order to use disk unfail : use " rc_toggle_basic " or " priv set advanced / admin" > >----- Original Message ----- >From: "Stephane Bentebba" <stephane.bentebba(a)fps.fr> >To: "Jordan Share" <iso9(a)jwiz.org> >Cc: "'Toasters(a)Mathworks.Com'" <toasters(a)mathworks.com> >Sent: Thursday, February 13, 2003 6:12 AM >Subject: Re: Adding a drive shelf to my existing F740 > > > > >>First : to be sure we speak the same language (I'm french) >>the raidsize include the parity disk. >>a group raid of sized 14 can contain up to 13 data disks and one parity >>disk. >>the max size of a raid can be 28 >> >>- the more disk in a raid you have, the more the filer need time to >>reconstruct the disk (and the longer the CPU is used for that). >>- larger the disk is, the more it consume time also. >>for exemple, a F760 with a cpu load average at 40% in production can go >>up to 50% during 6 hours to reconstruct a 72G disk >> >>1 - taking this into account, I won't advise you to move your raidsize >>to 28, but if you want to save as many as possible disk, you can turn >>the raidsize to 28 and add those 36G disks in the same raidgroup than >>other (18G) >>2 - there is an extra trick to save a spare disk : don't keep two but >>only one spare disks : a 36G one, as Filer can reconstruct a 18G broken >>disk on a 36G. BUT you have to order Netapp for a 36G after that >>failure. If you have a hardware contract with Netapp, take care >>because, when a 18G fail, they would send you a 18G too, not a 36G. You >>would have to check for that (look for a special deal ?) >> >>These two tricks apart, I can't see better ways than what you had plained >> >>Jordan Share wrote: >> >> >> >>>After reading further in my manuals, I've got some questions about the >>>RAIDgroup size. >>> >>>When I initially created the volume, I made the raidsize 14, so that it >>>would use 1 parity disk for the 14 disks we had at that time. >>> >>>Looking at it now, I kind of think that I want a raidsize of 13 for the >>>current volume (since one disk is a hot spare). >>> >>>So, I issued: >>>vol options vol0 raidsize 13 >>> >>>That worked ok, because now: >>> >>> >>> >>> >>>>vol status vol0 >>>> >>>> >>>> >>>> >>> Volume State Status Options >>> vol0 online normal root, raidsize=13 >>> raid group 0: normal >>> >>>Basically, what I'm trying to avoid here is having the first 36gig disk >>>added to the initial raidgroup. I believe changing the raidsize to 13 >>> >>> >will > > >>>have fixed that, since now that raidgroup is full, and additional disks >>> >>> >will > > >>>go into their own raidgroup. >>> >>>I welcome (and request. :) all comments on this post. >>> >>>Thanks very much, >>>Jordan Share >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: owner-toasters(a)mathworks.com >>>>[mailto:owner-toasters@mathworks.com]On Behalf Of devnull(a)adc.idt.com >>>>Sent: Wednesday, February 12, 2003 11:28 AM >>>>To: Jordan Share >>>>Cc: 'Toasters(a)Mathworks.Com' >>>>Subject: Re: Adding a drive shelf to my existing F740 >>>> >>>> >>>> >>>> >>>> >>>> >>>>>As I understand it, I would then have 2 hot spares (18 and 36), and two >>>>>drives for parity. >>>>> >>>>> >>>>> >>>>> >>>>Yup. >>>> >>>>You would need the separate spare to accomodate the difference in drive >>>>sizes. The parity drive is a function of RAID 4. >>>> >>>>We did the same about a year back on our 740 and it worked well. >>>> >>>> >>>> >>>> >>>> >>>>>Are there any "gotchas" (or blatant ignorance on my part) in >>>>> >>>>> >>>>> >>>>> >>>>this scenario? >>>>It was mostly smooth. Though you might need to upgrade your ONTAP >>>> >>>> >version > > >>>>to 6.1.1R2 atleast >>>> >>>> >>>> >>>>/dev/null >>>> >>>>devnull(a)adc.idt.com >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> > > > > **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

1 0

RE: using vol0
by Alan McLachlan 14 Feb '03

14 Feb '03

Simon, Assuming you have a copy on a server drive or CD somewhere with the version of Data Ontap you're running, all you need is boot floppies (for non-flash units), and a copy of the config files (rc, hosts, exports, cifsconfig.cfg, lclgroups.cfg etc). Providing you keep a backup of the config files - many of my customers simply replicate the files in the /etc directory without all the subdirs to a folder on a couple of other servers. The config files all used to fit on a floppy. In a full blown DR scenario you can then have the root volume online and ready within a few minutes, unless disks need to be zero'd then it might take 20-30 minutes. You can than start restoring the rest of the root volume (home directories, workgroup data etc). The only time this wouldn't work is if you used "snap mirror to tape" for bare-metal restores rather than regular NDMP backups. regards, Alan. -----Original Message----- From: Clawson, Simon [mailto:simon_clawson@mentorg.com] Sent: Thursday, 13 February 2003 8:31 PM To: toasters(a)mathworks.com Subject: RE: using vol0 The only benefit as I see it to having the smallest possible vol0 is recovery time. You can back up and recover the small amount of data in a few minutes on most tape devices, meaning you are up and running fairly quickly in the event of losing the volume. However, there are methods of replicating the /etc data to another volume, then telling the filer to boot this as vol0. This would of course mean any NIS maps etc are broken until you change their paths, but the filer would be up and running quicker than if you were to have to restore the whole root volume first, and you would not be using two 72Gb disks for 40mb of data. **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

1 0

wafl scan reallocate not improving layout?
by Art Hebert 13 Feb '03

13 Feb '03

I have a volume that shows a layout of 5 when doing a wafl scan measure layout. I have tried reallocating it but it never gets below 5. Using statit the data seems to be laid out evenly, 4.2 is the parity disk. disk ut% xfers ureads--chain-usecs writes--chain-usecs cpreads-chain-usecs /vol/vol0 group 0: 4.2 3 4.22 0.43 1.00 23079 2.72 3.80 2986847599971 1.06 2.46 2182 4.4 39 79.56 77.18 1.91 2574 1.33 4.46 3793820692012 1.04 2.40 2365 4.1 37 76.72 74.81 1.91 2553 0.93 5.28 3193299281907 0.97 3.02 1613 4.6 41 83.67 81.56 1.88 2624 1.35 4.72 2462422822812 0.76 2.51 2198 4.0 40 83.62 81.77 1.87 2562 1.03 5.83 2711737467108 0.82 2.61 1959 4.3 40 83.70 81.83 1.86 2594 1.06 5.74 2738534194560 0.81 2.47 2055 4.5 40 84.04 82.17 1.86 2579 1.07 5.72 2611584689054 0.80 2.50 2099 Should I cease activity to the filer and run the wafl reallocate then? Thoughts and thanks art -----Original Message----- From: jwitham(a)takedapharm.com [mailto:jwitham@takedapharm.com] Sent: Tuesday, January 28, 2003 10:39 AM To: Ambrose_Earle(a)shamrockfoods.com; toasters(a)mathworks.com Subject: RE: wafl scan We use 'wafl scan reallocate' weekly to reorder our Exchange 5.5 databases. They keep growing, and are over 100GB apiece. The wafl scan reallocate helps our use of SnapManager verifications greatly. We have been known to run it in the middle of the day, but with a big performance hit (as you have seen). Haven't tried it in conjunction with SnapMirror. Just for grins, we also use 'wafl scan measure_layout' before and after the reallocate to ensure that we've accomplished something. We affectionately refer to the process as 'reshuffling the wafl house'. HTH, -john -----Original Message----- From: Ambrose_Earle(a)shamrockfoods.com [ mailto:Ambrose_Earle@shamrockfoods.com <mailto:Ambrose_Earle@shamrockfoods.com> ] Sent: Thursday, January 23, 2003 7:28 PM To: toasters(a)mathworks.com Subject: wafl scan Does anyone have any (good) experience with the wafl scan commands? I am testing Snapmirror and used it to mirror 7x34's to 10x34's. Of course, the data was only written to the first seven drives, so I used 'wafl scan reallocate <volume>' and it seemed to improve the layout quite dramatically. Is this a good use of the command? Other than affecting performance, I'm assuming everything is accessible during the run of this command? Thanks in advance, This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

1 0

Checking netapp for bad blocks?
by Art Hebert 13 Feb '03

13 Feb '03

Our oracle database has experienced two problems lately with file corruption on our standby database. The corruption isn't on the primary database and our Oracle DBA is asking if I can do something similar to fsck on the netapp. Any thoughts on the commands to run and what to check for would be appreciated. art -----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: Thursday, February 13, 2003 5:49 AM To: Jonathan Cc: Jordan Share; 'Toasters(a)Mathworks.Com' Subject: Re: Adding a drive shelf to my existing F740 Jonathan wrote: >>2 - there is an extra trick to save a spare disk : don't keep two but >>only one spare disks : a 36G one, as Filer can reconstruct a 18G broken >>disk on a 36G. BUT you have to order Netapp for a 36G after that >>failure. If you have a hardware contract with Netapp, take care >>because, when a 18G fail, they would send you a 18G too, not a 36G. You >>would have to check for that (look for a special deal ?) >> > >To add to your trick #2, Don't worry about getting a 18GB back from Netapp >and leaving your 36 acting like a 18. Simply add the 18 in the place of the >failed 18 and let the filer take it as a spare. Then do a disk fail on the >36 acting as a 18. The filer will now look for a spare 18 and find the new >spare to rebuild the raid group. Then do a disk unfail on the 36 acting as a >18 and Ontap will zero the 36 and put it back as a 36 spare. So you don't >need to work out a special deal with Netapp. I have done this many times and >with great success. > > of course ! i knew it indeed, what a dumb I am :) you have to switch mode in order to use disk unfail : use " rc_toggle_basic " or " priv set advanced / admin" > >----- Original Message ----- >From: "Stephane Bentebba" <stephane.bentebba(a)fps.fr> >To: "Jordan Share" <iso9(a)jwiz.org> >Cc: "'Toasters(a)Mathworks.Com'" <toasters(a)mathworks.com> >Sent: Thursday, February 13, 2003 6:12 AM >Subject: Re: Adding a drive shelf to my existing F740 > > > > >>First : to be sure we speak the same language (I'm french) >>the raidsize include the parity disk. >>a group raid of sized 14 can contain up to 13 data disks and one parity >>disk. >>the max size of a raid can be 28 >> >>- the more disk in a raid you have, the more the filer need time to >>reconstruct the disk (and the longer the CPU is used for that). >>- larger the disk is, the more it consume time also. >>for exemple, a F760 with a cpu load average at 40% in production can go >>up to 50% during 6 hours to reconstruct a 72G disk >> >>1 - taking this into account, I won't advise you to move your raidsize >>to 28, but if you want to save as many as possible disk, you can turn >>the raidsize to 28 and add those 36G disks in the same raidgroup than >>other (18G) >>2 - there is an extra trick to save a spare disk : don't keep two but >>only one spare disks : a 36G one, as Filer can reconstruct a 18G broken >>disk on a 36G. BUT you have to order Netapp for a 36G after that >>failure. If you have a hardware contract with Netapp, take care >>because, when a 18G fail, they would send you a 18G too, not a 36G. You >>would have to check for that (look for a special deal ?) >> >>These two tricks apart, I can't see better ways than what you had plained >> >>Jordan Share wrote: >> >> >> >>>After reading further in my manuals, I've got some questions about the >>>RAIDgroup size. >>> >>>When I initially created the volume, I made the raidsize 14, so that it >>>would use 1 parity disk for the 14 disks we had at that time. >>> >>>Looking at it now, I kind of think that I want a raidsize of 13 for the >>>current volume (since one disk is a hot spare). >>> >>>So, I issued: >>>vol options vol0 raidsize 13 >>> >>>That worked ok, because now: >>> >>> >>> >>> >>>>vol status vol0 >>>> >>>> >>>> >>>> >>> Volume State Status Options >>> vol0 online normal root, raidsize=13 >>> raid group 0: normal >>> >>>Basically, what I'm trying to avoid here is having the first 36gig disk >>>added to the initial raidgroup. I believe changing the raidsize to 13 >>> >>> >will > > >>>have fixed that, since now that raidgroup is full, and additional disks >>> >>> >will > > >>>go into their own raidgroup. >>> >>>I welcome (and request. :) all comments on this post. >>> >>>Thanks very much, >>>Jordan Share >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: owner-toasters(a)mathworks.com >>>>[mailto:owner-toasters@mathworks.com]On Behalf Of devnull(a)adc.idt.com >>>>Sent: Wednesday, February 12, 2003 11:28 AM >>>>To: Jordan Share >>>>Cc: 'Toasters(a)Mathworks.Com' >>>>Subject: Re: Adding a drive shelf to my existing F740 >>>> >>>> >>>> >>>> >>>> >>>> >>>>>As I understand it, I would then have 2 hot spares (18 and 36), and two >>>>>drives for parity. >>>>> >>>>> >>>>> >>>>> >>>>Yup. >>>> >>>>You would need the separate spare to accomodate the difference in drive >>>>sizes. The parity drive is a function of RAID 4. >>>> >>>>We did the same about a year back on our 740 and it worked well. >>>> >>>> >>>> >>>> >>>> >>>>>Are there any "gotchas" (or blatant ignorance on my part) in >>>>> >>>>> >>>>> >>>>> >>>>this scenario? >>>>It was mostly smooth. Though you might need to upgrade your ONTAP >>>> >>>> >version > > >>>>to 6.1.1R2 atleast >>>> >>>> >>>> >>>>/dev/null >>>> >>>>devnull(a)adc.idt.com >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> > > > >

1 0

F760 thinks it has 2 shelves with ID2
by Daniel Finn 13 Feb '03

13 Feb '03

Had another (different) Netapp crash last night. One thing I don't understand is why it decided to rewrite/recompute parity? Is that normal. There's nothing abnormal in the logs above where it starts to rebuild parity. It seems it crashed because it found two shelves with ID 2, but we haven't touched this in forever and the shelf IDs should've have changed. Would it be possible for this netapp to have been functioning all this time (+6 months) with two shelves with the same ID? Here's the excerpt from the logs: Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 0, stripe #2884782. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884788. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884793. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884797. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 0, stripe #2884790. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884803. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884804. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 0, stripe #2884804. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 3, stripe #2884789. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 3, stripe #2884792. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 3, stripe #2884796. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884779. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884789. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884796. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884800. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884801. Thu Feb 13 00:54:45 GMT [raid_stripe_owner:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884802. Wed Feb 12 19:22:50 EST [kern.syslog.msg:error]: Multiple shelves with ID 2 found on channel 4. Wed Feb 12 19:22:50 EST [sk.panic:ALERT]: reason="Multiple shelves with ID 2 found on channel 4. in process ses_admin on release NetApp Release 6.1.3" Wed Feb 12 19:54:09 EST [kern.syslog.msg:info]: Ethernet e0: Link up. Wed Feb 12 19:54:20 EST [kern.syslog.msg:error]: Enclosure Services unavailable for one or more shelves on channel 4. Wed Feb 12 19:54:34 EST [kern.syslog.msg:info]: Reinitializing checksum blocks on volume vol1. Wed Feb 12 19:54:35 EST [kern.syslog.msg:info]: Reinitializing checksum blocks on volume vol0. Wed Feb 12 19:54:41 EST [kern.syslog.msg:info]: Starting RAID checksum upgrade phase 1 (of 2) on volume vol1. Wed Feb 12 19:54:41 EST [kern.syslog.msg:notice]: Beginning parity recomputation on volume vol1, RAID group 0. Wed Feb 12 19:54:41 EST [kern.syslog.msg:notice]: Beginning parity recomputation on volume vol1, RAID group 1. Wed Feb 12 19:54:41 EST [kern.syslog.msg:notice]: Beginning parity recomputation on volume vol1, RAID group 2. Wed Feb 12 19:54:41 EST [kern.syslog.msg:notice]: Beginning parity recomputation on volume vol1, RAID group 3. Wed Feb 12 19:54:41 EST [kern.syslog.msg:notice]: Skipping parity recomputation on volume vol0, RAID group 0 (no dirty ranges). Wed Feb 12 19:54:42 EST [kern.syslog.msg:notice]: The system was down for 1879 seconds Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 0, stripe #2884782. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884788. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884793. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884797. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 0, stripe #2884790. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884803. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 1, stripe #2884804. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 0, stripe #2884804. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 3, stripe #2884789. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 3, stripe #2884792. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 3, stripe #2884796. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884779. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884789. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884796. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884800. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884801. Wed Feb 12 19:54:45 EST [kern.syslog.msg:notice]: Rewriting parity on volume vol1, RAID group 2, stripe #2884802. Wed Feb 12 19:54:50 EST [dyn_dev_qual_admin:info]: Firmware is up-to-date on all disk drives Wed Feb 12 19:54:50 EST [pvif.switchLink:warning]: trunk: switching to e0 Wed Feb 12 19:54:50 EST [ltm services:info]: Ethernet e1a: Link up. Wed Feb 12 19:54:50 EST [net_e0:info]: arp info overwritten for 10.100.26.11 by 00:00:0c:07:ac:3d Wed Feb 12 19:54:51 EST [ltm services:info]: Ethernet e1d: Link up. Wed Feb 12 19:54:54 EST [rc:ALERT]: timed: time daemon started Wed Feb 12 19:54:54 EST [CIFSAdmin:info]: Connection with DC \\N2M-BE established Wed Feb 12 19:54:54 EST [mgr.boot.disk_done:info]: NetApp Release 6.1.3 boot complete. Last disk update written at Wed Feb 12 19:22:31 EST 2003 Wed Feb 12 19:54:54 EST [mgr.boot.reason_abnormal:ALERT]: System rebooted after a panic. Wed Feb 12 19:54:54 EST [mgr.stack.saved:notice]: Reboot with saved panic information in log file Wed Feb 12 19:54:54 EST [mgr.stack.string:notice]: Panic string: Multiple shelves with ID 2 found on channel 4. in process ses_admin on release NetApp Release 6.1.3 Wed Feb 12 19:54:54 EST [mgr.stack.at:notice]: Panic occurred at: Thu Feb 13 00:22:49 2003 Wed Feb 12 19:54:54 EST [mgr.stack.proc:notice]: Panic in process: ses_admin Wed Feb 12 19:54:55 EST [mgr.stack.framename:notice]: Stack frame 0: sk_panic(0xfffffc00005e64f0) + 0x394 Wed Feb 12 19:54:56 EST [mgr.stack.framename:notice]: Stack frame 1: ses_scan(0xfffffc00006fcf10) + 0x638 Wed Feb 12 19:54:56 EST [mgr.stack.framename:notice]: Stack frame 2: ses_handle_signal(0xfffffc0000702090) + 0x39c Wed Feb 12 19:54:56 EST [mgr.stack.framename:notice]: Stack frame 3: SesAdmin(0xfffffc0000702790) + 0x1dc Wed Feb 12 19:54:56 EST [mgr.stack.framename:notice]: Stack frame 4: sk_hw_save_state_and_loop(0xfffffc00003f92e0) + 0x70

1 0

Adding a drive shelf to my existing F740
by Jordan Share 13 Feb '03

13 Feb '03

We're getting a bit tight on space, and I'd like to add a drive shelf to my F740. Right now, we have 2 full shelves of 18gig drives, with 1 for parity and 1 for hot spare. What I had planned to do was get a shelf of 36gig drives, and create a second raid group, then add it to the existing volume. As I understand it, I would then have 2 hot spares (18 and 36), and two drives for parity. Are there any "gotchas" (or blatant ignorance on my part) in this scenario? Thanks, Jordan

4 5

RE: NDMP issues with 6.2.x of DataONTAP
by Jay Newton (Email) 13 Feb '03

13 Feb '03

NetApp did confirm that NDMP went from V3 to V4 from 6.1.x to 6.2.x. I tried forcing the Filer back to NDMP V3. It raced the processors up to 100% and stayed there. I had fewer backups running as well. I can't explain that behavior other than something in how DOT talks to NDMP must have changed. Have you tried this and what were your experiences? Thank you for your information. -----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: Wednesday, February 12, 2003 7:35 AM To: Jay Newton (Email) Cc: 'toasters(a)mathworks.com' Subject: Re: NDMP issues with 6.2.x of DataONTAP Jay Newton (Email) wrote: > We are experiencing issues with NDMP backups. I'm hoping other people > in this group have seen it as well and may have suggestions for us to > try. Here's an explanation of what has happened. > > On 12-13-2002 we upgraded from 6.1.3r2 to 6.2.1r2 to fix issues with > Autosupports not being sent in the event of hardware failure. A > couple of things went sour after the upgrade. Our SnapManager for > Exchange performance went down more than 30%, NDMP backups would run > slow intermittently, and general Filer performance got worse. NetApp > discovered a memory leak in 6.2.1r2 in the NDMP daemon about the same > time we upgraded to 6.2.1r2. We had to upgrade to 6.2.2d8 to fix that > issue. However, a backup or two will invariably run slower than the > rest. If the backup is restarted, it usually picks up speed and runs > normally. By slow I mean 10 gigs in 10 hours on a DLT8000 drive. I > used to get 20-30 gig per hour before we upgraded to 6.2.1r2. This > can happen with each of the 4 DLT8000 drives attached to the Filer > meaning that I can't pin the problem to a bad piece of hardware. > > Today we have discovered that snapshots for backup are not deleting > correctly. The NDMPD process was holding the snapshot hostage. A > volume ran out of space due to this issue. We were able to kill the > NDMPD sessions that were holding the snapshot open and the snapshot > deleted normally. > > Has anyone else experienced similar issues? > > For those of you running SnapManager for Exchange, how big are your > databases and how long does it take to verify them? Also, those who > run multiple backups, what is your CPU utilization like when running 4 > simultaneous backups and what is your tape throughput? > > DataONTAP 6.2.2d8 > Commvault Galaxy 3.7.1 SP4 > ATL P2000 library with 4 DLT8000 drives attached to Filer on 2 SCSI > HVD controllers (2 drives per controller) > > Thanks! > > > Jay Newton > Systems Engineer > Chesapeake Energy Corporation > Natural Gas - Natural Advantages > Building 6112, Room 114 > (405)848-8000 ext. 683 > jnewton(a)chkenergy.com > I am not sure of what I say but, try to figure out if ndmp max version of Ontapp didn't switch from 3 to 4 beetween your different Ontapp . if so, try to force the ndmp max version back to 3 (in case it is not fully supported by your backup software application) with this command : ( ndmpd version gives you the current max version) ndmpd version 3 then make a try and decide ( to set back the max version to 4, type ndmpd version 4 ) from my point of view, it could explain our performance problem and more certainly your zombie ndmp sessions.

2 1

F210 password recovery
by dan radom 13 Feb '03

13 Feb '03

I've acquired a Net App F210 running dataontap NetApp Release 5.2.1 through a merger, and I'm needing to know how to reset the password. Any suggestions would be greatly appreciated. dan

2 1

removing a disk from a volume?
by Peter D. Gray 13 Feb '03

13 Feb '03

Is there a way to remove a disk from a volume permanently. I want to move from 18GB drives to 36GB drives and I was hoping to do it with no downtime by removing the 18Gb drives one at a time and replacing with 36GB drives. Possible or is there a better way? Regards, pdg -- See mail headers for contact information.

2 1

RE: using vol0
by Alan McLachlan 13 Feb '03

13 Feb '03

Hi Charles, Don't understand why you're asking this. In most cases that I'm aware of vol0 is used for data. In some cluster scenarious, particularly with local or remote syncmirror, it becomes necessary to burn two disks to have a root volume that's just for the filer's config files - usually only on one half of the cluster. I can't imagine apart from that why someone would want to consume two whole drives for the 40MB or so of data in the /etc directory. In fact, many of my customers have only configured a second volume in order to support a database. User home directories and workgroup data stay on vol0. You should of course make use of qutoa'd qtrees within vol0 extensively to prevent it filling up - theoretically this could cause a panic in some circumstances although Data OnTap is much more robust than a Unix or Linux in this regard. ---------------------------------------------------------------------------- --------------------------- On a related note, one issue that crops up from time to time is that when a filer is used to replace a bunch of Windows fileservers on a large CIFS network, it can happen that well-meaning Domain Admins that don't directly look after the filer and aren't trained in Data OnTAP may accidently corrupt config files in the /etc directory. It would be nice to restrict access to just a select group of trained admins. Using a Windows domain group is not the answer, as any Domain Admin can take ownership of the resource. A solution is to turn the /etc directory into a unix security style qtree: * make a new qtree called say "etcnew" * copy the files from /etc to /etcnew * rename /etc to "etcold" * rename /etcnew to "etc" * set the security style of etc to unix This works even if you only have a CIFS licence. You should then install ssaccess on a workstation to manage the security on the /etc qtree. Then, in the usermap.cfg file in /etc put an entry for each trusted admin like so: *\root => nobody (security defensive entry) DOMAIN\fred => root DOMAIN\wilma => root As the final step, set options wafl.nt_admin_priv_map_to_root to OFF. The result is that, in the example above, only the domain users "fred" and "wilma" can make changes to the /etc directory. For all the other resources on the filer (which have NTFS security style), normal domain security rules apply. -----Original Message----- From: Charles Bartels [mailto:cbartels@openharbor.com] Sent: Wednesday, 12 February 2003 3:45 AM To: toasters(a)mathworks.com Subject: using vol0 Hi, I'm configuring an F810 and space is going to be a little tight. How do people feel about adding disks to vol0 and using that instead of creating a whole separate volume (and burning a another parity disk) ? -Charles Bartels **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

1 0

Re: mixed mode .vs unix mode qtrees on a NFS & CIFS filer
by Rune Bakken 13 Feb '03

13 Feb '03

"Colin Eric Johnson" <colinj(a)ccs.neu.edu> writes: > Here's the trouble I'm running into and the question that it > raises. > > I'm getting ready to turn on CIFS on our filer (F820) so that our > users have one file system to deal with and not two. In my > experiments I have seen some strange behavior that goes something > like this: > > If the qtrees are unix mode then my unix host that has root privs > can see and manipulate files just fine. > > If the qtrees are mixed mode then on some files the unix host can > manipulate files and on some it cannot. > > It can even get to the point that a file/directory that a user > creates under windows cannot be accessed by that same user from > unix (if the filer is in mixed mode). > > So, my questions are: > > 1. Has anyone seen this behavior before? Often enough that we decided to go away from mixed mode. We have ended up selecting unix on filesystems mostly accessed by unix users and ntfs on filesystems mainly used by windows users. It seemed to create less confusion that way. I haven't tried mixed mode witj ONTAP 6.x though. >>>>>>>>.rune -- Rune Bakken Senior System Administrator Telenor Business Solutions (Nextra), ManagedServices/*/IP-Services http://ips.telenor.net/

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