toasters

toasters@lists.teaparty.net

13514 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters