toasters February 2003

toasters@lists.teaparty.net

104 participants
136 discussions

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

[RE: removing a disk from a volume?]
by Peter D. Gray 12 Feb '03

12 Feb '03

Thanks you all the people that responded to this. It sounds like there is no real easy solution, although people did have specific suggestions (snapmirror, ndmpcopy etc). Many thanks, pdg

1 0

mixed mode .vs unix mode qtrees on a NFS & CIFS filer
by Colin Eric Johnson 12 Feb '03

12 Feb '03

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? 2. If a user disappears from Active Directory and I have to recreate them will the new SID be a problem if the user has the same name? 3. Does anyone have any thoughts on which security mode (unix or mixed) for a filer that is serving NFS to an NIS domain and CIFS to a Windows AD Domain? Thanks Colin J.

2 1

Free Disk Shelves - Non-Profit Organizations
by Allen, Pat 12 Feb '03

12 Feb '03

I apologize for the improper use of the list and I hope I don't attract too many flames. But I hope that I can be forgiven considering the potential good to be derived from the posting. We have just retired two FC-8 disk shelves which are fully populated with 18GB disks. The shelves and disks are in great shape. As a non-profit organization we are willing to donate these to other non-profit organizations. All we ask is that you supply an account for shipping. Please only reply to this post if you are a non-profit organization and have a need for this storage. --- Pat Allen (pat(a)mbari.org) Monterey Bay Aquarium Research Institute (MBARI) 7700 Sandholdt Rd, Moss Landing, CA 95039 (voice) 831-775-1724; (fax) 831-775-1620

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
14
Older →

Jump to page:

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 February 2003