toasters

toasters@lists.teaparty.net

13531 discussions

RE: Removing a shelf.
by Leeds, Daniel 13 Nov '08

13 Nov '08

you are 100% correct. the ability to hot-remove shelves that contain no data would be an incredible value gain. we are currently migrating into a multistore scenario in which we can do planned migrations of all data from one filer cluster to another and free up the original filer for maintenance tasks without any extended downtime or change to the clients in our NFS environments. this is the next best thing while GX merges back into the current 7.x base down the road. we get planned maintenance windows of one hour or less and the ability to run environments without change on a different set of filer heads. ontap upgrades, hardware swaps, environment migrations much less painful and actually doable at this point. we have tons of 72/144gb drives to swap out before their support expiry in 2011 :) good luck to the OP. -- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404 310-309-4999 desk 310-430-0536 cell -----Original Message----- From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] Sent: Thu 11/13/2008 3:27 PM To: Leeds, Daniel Cc: Nils Vogels; Ray Van Dolson; toasters(a)mathworks.com Subject: Re: Removing a shelf. If youre not so lucky, you can lose visibility to an entire random shelf on the system, forcing the rebuild of X missing drives. I have seen this happen, and after a hard shutdown of all devices to re-map the loops, it all comes back, but you're still stuck rebuilding missing drives from the unsupported pull. On Thu, Nov 13, 2008 at 3:03 PM, Leeds, Daniel <dleeds(a)edmunds.com> wrote: > > yes, i neglected to mention we did a clean shutdown shortly after. this was > coordinated as a way to fix an urgent need which it sounded like the > original poster had in regards to sending a loaner shelf back. > > it did function fine without any issues until an approved downtime window > could be scheduled. > > in most of our environments we have zero ability for any downtime scheduled > or otherwise which is really killing us with a current shelf bug causing > drives to randomly go amber and support recommends power cycling the shelf > to correct it + updated firmware--but thats a whole other story. > > --daniel > > -- > Daniel Leeds > Manager, Storage Operations > Edmunds, Inc. > 1620 26th Street, Suite 400 South > Santa Monica, CA 90404 > > 310-309-4999 desk > 310-430-0536 cell > > > > -----Original Message----- > From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] > Sent: Thu 11/13/2008 3:01 PM > To: Leeds, Daniel > Cc: Nils Vogels; Ray Van Dolson; toasters(a)mathworks.com > Subject: Re: Removing a shelf. > > Daniel: > > I would check with support, IIRC, hot removing a shelf is _really_ > frowned upon, and can cause mapping issues that can lead to > _requiring_ you to power down all nodes and shelves to correct. > > Even in failover mode, shelf mapping is persistent. > > https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb40710 > > > > > > >> Daniel Leeds >> Manager, Storage Operations >> Edmunds, Inc. >> 1620 26th Street, Suite 400 South >> Santa Monica, CA 90404 >> >> 310-309-4999 desk >> 310-430-0536 cell >> >> >> >> -----Original Message----- >> From: owner-toasters(a)mathworks.com on behalf of Nils Vogels >> Sent: Thu 11/13/2008 1:16 PM >> To: Ray Van Dolson >> Cc: toasters(a)mathworks.com >> Subject: Re: Removing a shelf. >> >> Hey Ray, >> >> On Thu, Nov 13, 2008 at 9:31 PM, Ray Van Dolson <rvandolson(a)esri.com> >> wrote: >>> >>> An aggregate spans two shelves, one of which is the shelf that needs to >>> be returned. This aggregate contains a FlexVol currently in use. I'd >>> like to preserve the FlexVol but remove the shelf. >> >> If you can afford the downtime, you could offline the aggregate >> concerned, swap the disks into the shelf that can remain, and online >> the aggregate again. Should be a few minutes. >> >> Another way, which does take a lot longer, is to use "disk replace" to >> copy the used disks from their old position to their new ones. No >> downtime, but the disks get copied one at a time, which can be a few >> hours. >> >> HTH & HAND >> >> -- >> Simple guidelines to happiness: >> Work like you don't need the money, >> Love like your heart has never been broken and >> Dance like no one can see you. >> >> > >

1 0

RE: Removing a shelf.
by Leeds, Daniel 13 Nov '08

13 Nov '08

yes, i neglected to mention we did a clean shutdown shortly after. this was coordinated as a way to fix an urgent need which it sounded like the original poster had in regards to sending a loaner shelf back. it did function fine without any issues until an approved downtime window could be scheduled. in most of our environments we have zero ability for any downtime scheduled or otherwise which is really killing us with a current shelf bug causing drives to randomly go amber and support recommends power cycling the shelf to correct it + updated firmware--but thats a whole other story. --daniel -- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404 310-309-4999 desk 310-430-0536 cell -----Original Message----- From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] Sent: Thu 11/13/2008 3:01 PM To: Leeds, Daniel Cc: Nils Vogels; Ray Van Dolson; toasters(a)mathworks.com Subject: Re: Removing a shelf. Daniel: I would check with support, IIRC, hot removing a shelf is _really_ frowned upon, and can cause mapping issues that can lead to _requiring_ you to power down all nodes and shelves to correct. Even in failover mode, shelf mapping is persistent. https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb40710 > Daniel Leeds > Manager, Storage Operations > Edmunds, Inc. > 1620 26th Street, Suite 400 South > Santa Monica, CA 90404 > > 310-309-4999 desk > 310-430-0536 cell > > > > -----Original Message----- > From: owner-toasters(a)mathworks.com on behalf of Nils Vogels > Sent: Thu 11/13/2008 1:16 PM > To: Ray Van Dolson > Cc: toasters(a)mathworks.com > Subject: Re: Removing a shelf. > > Hey Ray, > > On Thu, Nov 13, 2008 at 9:31 PM, Ray Van Dolson <rvandolson(a)esri.com> wrote: >> >> An aggregate spans two shelves, one of which is the shelf that needs to >> be returned. This aggregate contains a FlexVol currently in use. I'd >> like to preserve the FlexVol but remove the shelf. > > If you can afford the downtime, you could offline the aggregate > concerned, swap the disks into the shelf that can remain, and online > the aggregate again. Should be a few minutes. > > Another way, which does take a lot longer, is to use "disk replace" to > copy the used disks from their old position to their new ones. No > downtime, but the disks get copied one at a time, which can be a few > hours. > > HTH & HAND > > -- > Simple guidelines to happiness: > Work like you don't need the money, > Love like your heart has never been broken and > Dance like no one can see you. > >

1 0

Snapvault slow on one specific volume?
by Page, Jeremy 13 Nov '08

13 Nov '08

I have an aggr with two volumes on it. One of them is a 3.5 TB CIFS/NFS share that is reasonably fast to snapvault and a 1 TB NFS share (ESX VMs) that is exceptionally slow. As in it's been doing it's initial copy for over a week and still has not finished. NDMP backups of this volume are also quite slow, does anyone know why it would be so much slower then the other volume using the same spindles? The filer is not under extreme load, although occasionally it's pretty busy. Here is a "normal" sysstat: CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 12% 1007 2970 8996 15769 9117 0 0 8 93% 49% : 41% 18% 920 2792 6510 11715 6924 0 0 8 99% 84% T 39% 15% 1276 3580 10469 15942 8041 0 0 10 92% 33% T 36% 13% 1487 3416 11347 15632 4907 0 0 11 89% 42% : 43% 17% 1417 3180 9890 14000 9444 0 0 9 98% 79% T 41% 13% 972 3704 9705 15427 9934 0 0 7 92% 46% T 51% 18% 1087 2947 11911 17717 4640 0 0 9 98% 33% T 47% 11% 1204 3358 11219 14090 5159 0 0 7 88% 100% : 50% 12% 1161 2808 9085 12640 5936 0 0 9 90% 33% T 44% 13% 981 4735 11919 16125 7097 0 0 9 92% 45% : 43% 15% 1158 5780 12480 17565 8266 0 0 10 92% 88% T 41% I'm just having difficulty trying to determine why two volumes on the same spindles would be so different in the time it takes to do their initial transfer. Also, the VM's do not seem slower then those hosted on other aggregates (this one is 3 RG of 11 disks each, Ontap 7.2.4 on a 3070A IBM rebranded). This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

7 15

Re: writes through NVRAM *also* in read cache?
by Blackmor, Chris 13 Nov '08

13 Nov '08

Writes are also put into read cache. If you have a highly cache dependent file system on a filer with high writes you are also caching those and will roll what is in cache more. We ended up moving our tools repos to low write filers to alleviate the problems we were experiencing from this. C- ----- Original Message ----- From: owner-toasters(a)mathworks.com <owner-toasters(a)mathworks.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Thu Nov 13 11:09:05 2008 Subject: writes through NVRAM *also* in read cache? While I'm thinking of it... During a conversation with my sales rep., this question came up... (Haven't had a chance to ask our local SE's yet...) If a write happens through NVRAM (which it always does), once the write is acknowledged onto disk and the NVRAM flushed, is that data in read cache *as well*? Or, is the path to disk for a write unique, and when you want to read that data, it has to be read from disk and *then* put into read cache? I'm thinking of our software development environment, where we (of course) do a lot of writing of object files and then linking them into libraries and executables.... Until next time... The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

writes through NVRAM *also* in read cache?
by Todd C. Merrill 13 Nov '08

13 Nov '08

While I'm thinking of it... During a conversation with my sales rep., this question came up... (Haven't had a chance to ask our local SE's yet...) If a write happens through NVRAM (which it always does), once the write is acknowledged onto disk and the NVRAM flushed, is that data in read cache *as well*? Or, is the path to disk for a write unique, and when you want to read that data, it has to be read from disk and *then* put into read cache? I'm thinking of our software development environment, where we (of course) do a lot of writing of object files and then linking them into libraries and executables.... Until next time... The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

2 1

SV: Mounting read-only snapshots using open-iscsi?
by Karlsson Ulf Ibrahim :ULK 12 Nov '08

12 Nov '08

Hmm. I think it will be easier to buy a NFS license and just mount the flexvol containing the LUNs on the backup-server, then dump /mountpoint/.hourly-1/ or whatever. Running a Gentoo/Ubuntu/Linux shop without a NFS license seems odd, it's like buying a car without wheels... /Ulf -----Ursprungligt meddelande----- Från: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] För Romeo Theriault Skickat: den 12 november 2008 16:11 Till: David L. Lambert; Toasters Ämne: Re: Mounting read-only snapshots using open-iscsi? I'm not 100% sure of this, but I don't think you can map and mount a snapshot itself. (I may be wrong, someone please let me know if I am) but I believe that you'll need a flexclone license to create a clone of that particular snapshot and then map the clone to your backup host. On Wed, Nov 12, 2008 at 8:41 AM, David L. Lambert <dlambert(a)bmtcarhaul.com> wrote: We acquired a cluster of NetApp filers a few months ago with only an iSCSI license (no NFS or CIFS access), intending to use it for data volumes on our Linux and Windows hosts and later for virtualization. We have one production Gentoo system mounting a data volume from the filer using open-iscsi, and we have several other Gentoo and Ubuntu systems that we would like to configure that way as well. We also have an Ubuntu system connected to a tape library. We would like to take snapshots of the data-volumes that need to be backed up, mount those snapshots on the backup host, and do an incremental backup from the mounted filesystem. Probably we would partition each LUN with one Linux partition, and put an ext3 or reiserfs filesystem with a cluster-unique label on that partition. Then we could take a set of snapshots for the backup, map all the snapshot LUNs to the backup-host, do iSCSI discovery on the backup-host, mount each partition (listed in a configuration-file) with a "mount LABEL=..." command, perform the backup, unmount the partition, do an iSCSI logout, and delete all the snapshots. Has anyone gotten a setup like this to work? -- David Lee Lambert Software Developer, Precision Motor Transport Group, LLC 517-349-3011 x223 (work) ... 586-873-8813 (cell) -- Romeo Theriault

1 0

Nodes Sharing Spares
by Brian.Beaird＠cat.com 11 Nov '08

11 Nov '08

We are using the IBM n-series filers with our aggregates using dual-parity. Our filer is a dual-node controller, so each node independently owns different disks from the storage shelves. My question deals with how spare disks are allocated. With how it's currently set up, each node has to reserve two disks that it owns as spares to support dual parity. I don't know that we necessarily need four spares for such a relatively small number of physical disks (21 total). It seems pretty wasteful to have all that space just sitting there, especially when the chances of more than two disks failing before we can get replacements in are pretty slim. Is there some way to just let the nodes share a couple spares so that either one can grab them if failures occur in one of their owned disks? It would be great if I could free up one or two of those spares for actual use. I know there's a way to force spare disksk into aggregates, but I don't want to do this if that means one node won't have any spares to use. Thanks, Brian Beaird

7 8

cmd line vol create USABLE script anyone?
by Kevin M. Parker 10 Nov '08

10 Nov '08

I was about to put together a script that would vol create with desired *usable* space (calcs based on ['vol size' = 'desired_usable' + 'snap reserve' + WAFL overhead] .but thought someone on this planet must have done this before. Bueller? If none, I'll post when I'm done. TIA Best regards, ~~~~~~~~~~~~~~~~ Kevin Parker Mobile: 919.606.8737 http://theparkerz.com <blocked::http://theparkerz.com/> ~~~~~~~~~~~~~~~~

2 1

Re: LA Insight conference
by Fox, Adam 08 Nov '08

08 Nov '08

I'll be there. I think at least one night is free (aka no mandatory fun). I don't have the schedule in front of me now, but I may be game. -- Adam Fox ------------------------ Typed with my thumbs on a very small keyboard. ----- Original Message ----- From: Nicholas Bernstein <nick(a)nicholasbernstein.com> To: Toasters <toasters(a)mathworks.com> Sent: Sat Nov 08 00:02:22 2008 Subject: LA Insight conference Anyone else attending the conference in LA next week? I thought it might be fun to have a toasters meetup there. Cheers, Nick -- Nicholas Bernstein Technologist, Consultant, Instructor http://nicholasbernstein.com

1 0

LA Insight conference
by Nicholas Bernstein 08 Nov '08

08 Nov '08

Anyone else attending the conference in LA next week? I thought it might be fun to have a toasters meetup there. Cheers, Nick -- Nicholas Bernstein Technologist, Consultant, Instructor http://nicholasbernstein.com

1 0

R: SMSQL and verification issues
by Milazzo Giacomo 07 Nov '08

07 Nov '08

Hi all Tow and Andreas were right! And my premonition too J We've simply renamend the Windows path from uppercase to lowercase letters, disconnected and reconnected the LUNs in SD this mount points and verification server works fine now! Thank you very much to all of you Da: De Wit Tom (Consultant) [mailto:tom.de.wit@consultant.volvo.com] Inviato: venerdì 7 novembre 2008 11.23 A: Milazzo Giacomo; toasters(a)mathworks.com Oggetto: RE: SMSQL and verification issues Repost as previous post didn't seem to get through ... ________________________________ From: De Wit Tom (Consultant) Sent: vrijdag 7 november 2008 9:24 To: 'Milazzo Giacomo'; toasters(a)mathworks.com Subject: RE: SMSQL and verification issues Hi, I think its exactly like you say yourself. The database connection during verification is case sensitive. We had the exact same issue when starting to use volume mount points. The solution is to reattach the database with the exact same casing as the filepath on the server ! Grtz, Tom ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Milazzo Giacomo Sent: donderdag 6 november 2008 11:05 To: toasters(a)mathworks.com Subject: SMSQL and verification issues Importance: High Hi all, Up to now I've always set up SQL cluster with LUNs on drive letters and I've used a single stand alone SQL instance on the "passive" node of the cluster as verification server. Sincerely this is my first experience of SMSQL on a MS cluster using mount point and an external verification server. The scenario so is a SQL cluster using mount point instead of drive letters and an external verification server. We have the DB files on a LUN mounted as S:\DB01, the logs on another LUN mounted as S:\LOG01 and GLINKA0 as external verification server. Here follows the log. The backup is successfully done but when the verification starts something goes wrong: the snapshotted LUNs for DB and LOG are successfully mounted on Z: and Y: but SMSQL on verification does not find the db files a/o the log files looking for it on S:\DB01 (that is the path of the mount point!)... I hope this has nothing to do with capital or lowercase usage of paths J (we've S:\DB01 and S:\db01 on log...). From the verification server I can see the LUN mounted, I can browse them while are mounted and I can see the 'not found' files... Any idea? Thank you in advance, [09:28:45.992] *** VERIFY DATABASE AFTER BACKUP [09:28:45.992] Collecting verification information... [09:28:45.992] Getting database backup information from SnapInfo file... [09:28:45.992] Initializing SnapManager server on remote machine [GLINKA0]... [09:28:46.602] Mounting Snapshot [sqlsnap__amen01__recent] for Virtual Disk S:\DB01\ of Computer amen01 [09:29:15.180] This Snapshot is mounted as the drive [Z:]. [09:29:15.180] Mount Snapshot succeeded. [09:29:15.180] Mounting Snapshot [sqlsnap__amen01__recent] for Virtual Disk S:\LOG01\ of Computer amen01 [09:30:08.664] This Snapshot is mounted as the drive [Y:]. [09:30:08.664] Mount Snapshot succeeded. [09:30:08.664] Cannot find the data file in the mounted drive: [09:30:08.664] S:\db01\ale2.mdf [09:30:08.664] Dismounting Virtual Disk Z of SnapShot [sqlsnap__amen01__recent]... [09:30:25.429] Dismount Snapshot succeeded. [09:30:25.429] Dismounting Virtual Disk Y of SnapShot [sqlsnap__amen01__recent]... [09:30:31.476] Dismount Snapshot succeeded. [09:30:31.492] Unable to locate the database data file on the mounted disk drive. [09:30:31.492] Database verification information was not updated. [09:30:31.507] There is an error during database verification. [09:30:31.507] [09:30:31.507] **** FULL DATABASE BACKUP RESULT SUMMARY #1 **** [09:30:31.507] Backup Time: 11-06-2008_09.28.12 [09:30:31.507] Backup Group [#1]: [09:30:31.507] #1 : [amen01\amen01 - ale2] : Failed with error code 0xc0040814. [09:30:31.507] #1 : [amen01\amen01 - ale2] Error : Backup OK, but DBCC Skipped. [09:30:31.507] #2 : [amen01\amen01 - ale3] : Failed with error code 0xc0040814. [09:30:31.507] #2 : [amen01\amen01 - ale3] Error : Backup OK, but DBCC Skipped. [09:30:31.507] #3 : [amen01\amen01 - db4] : Failed with error code 0xc0040814. [09:30:31.507] #3 : [amen01\amen01 - db4] Error : Backup OK, but DBCC Skipped. [09:30:31.507] [09:30:31.507] *** SNAPMANAGER BACKUP JOB ENDED AT: [11-06-2008 09.30.31] [09:30:31.507] Unable to locate the database data file on the mounted disk drive.

1 1

RE: SMSQL and verification issues
by Buerger, Andreas 07 Nov '08

07 Nov '08

I think you guys are also running into BURT 233939, sadly it's not accessable through NOW. The key of that BURT is to make sure the mount point in the database path is exactly same as the mount point path in SnapDrive. For us the lun was mounted with in upper case in snapdrive, while the drive letter in the sql configuration was in lower case. Windows isn't case sensitve and doesn't care about those differences, but SM SQL does...I think it'll be fixed soon. You should check the mount paths carefully, I bet it's the same issue on your side. ________________________________ From: Milazzo Giacomo [mailto:G.Milazzo@sinergy.it] Sent: Thursday, November 06, 2008 8:03 PM To: Herring, Jason; Buerger, Andreas Subject: R: SMSQL and verification issues It seems we'ge got a bug J I'm in contact with some guy in NetApp US and I'll notify you any news as soon as I'll receive them,. Regards, Da: Herring, Jason [mailto:jherring@insightinvestments.com] Inviato: giovedì 6 novembre 2008 18.19 A: Buerger, Andreas; Milazzo Giacomo Oggetto: RE: SMSQL and verification issues Interesting timing, I was just about to help a customer setup something very similar to this w/ a remote verification server & they are using mount points. Would you mind including me on the resolution to this trouble ticket, or, pass on the ticket # so I can open one in advance and reference it? Thanks, Jason -----Original Message----- From: owner-toasters(a)mathworks.com on behalf of Buerger, Andreas Sent: Thu 11/6/2008 4:18 AM To: Milazzo Giacomo; toasters(a)mathworks.com Subject: RE: SMSQL and verification issues Hi, We'r running into the same problem with a Clustered MS SQL installation. There is an open case, but up to now no solution for the issue. The snapshoted LUN gets mounted correctly, but SMSQL doesn't find the DB files for verification... Whats your installed version of SnapDrive and SMSQL? Ours is SD 5.0 and SMSQL 2.1.1. Cheers Andreas ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Milazzo Giacomo Sent: Thursday, November 06, 2008 11:05 AM To: toasters(a)mathworks.com Subject: SMSQL and verification issues Importance: High Hi all, Up to now I've always set up SQL cluster with LUNs on drive letters and I've used a single stand alone SQL instance on the "passive" node of the cluster as verification server. Sincerely this is my first experience of SMSQL on a MS cluster using mount point and an external verification server. The scenario so is a SQL cluster using mount point instead of drive letters and an external verification server. We have the DB files on a LUN mounted as S:\DB01, the logs on another LUN mounted as S:\LOG01 and GLINKA0 as external verification server. Here follows the log. The backup is successfully done but when the verification starts something goes wrong: the snapshotted LUNs for DB and LOG are successfully mounted on Z: and Y: but SMSQL on verification does not find the db files a/o the log files looking for it on S:\DB01 (that is the path of the mount point!)... I hope this has nothing to do with capital or lowercase usage of paths J (we've S:\DB01 and S:\db01 on log...). From the verification server I can see the LUN mounted, I can browse them while are mounted and I can see the 'not found' files... Any idea? Thank you in advance, [09:28:45.992] *** VERIFY DATABASE AFTER BACKUP [09:28:45.992] Collecting verification information... [09:28:45.992] Getting database backup information from SnapInfo file... [09:28:45.992] Initializing SnapManager server on remote machine [GLINKA0]... [09:28:46.602] Mounting Snapshot [sqlsnap__amen01__recent] for Virtual Disk S:\DB01\ of Computer amen01 [09:29:15.180] This Snapshot is mounted as the drive [Z:]. [09:29:15.180] Mount Snapshot succeeded. [09:29:15.180] Mounting Snapshot [sqlsnap__amen01__recent] for Virtual Disk S:\LOG01\ of Computer amen01 [09:30:08.664] This Snapshot is mounted as the drive [Y:]. [09:30:08.664] Mount Snapshot succeeded. [09:30:08.664] Cannot find the data file in the mounted drive: [09:30:08.664] S:\db01\ale2.mdf [09:30:08.664] Dismounting Virtual Disk Z of SnapShot [sqlsnap__amen01__recent]... [09:30:25.429] Dismount Snapshot succeeded. [09:30:25.429] Dismounting Virtual Disk Y of SnapShot [sqlsnap__amen01__recent]... [09:30:31.476] Dismount Snapshot succeeded. [09:30:31.492] Unable to locate the database data file on the mounted disk drive. [09:30:31.492] Database verification information was not updated. [09:30:31.507] There is an error during database verification. [09:30:31.507] [09:30:31.507] **** FULL DATABASE BACKUP RESULT SUMMARY #1 **** [09:30:31.507] Backup Time: 11-06-2008_09.28.12 [09:30:31.507] Backup Group [#1]: [09:30:31.507] #1 : [amen01\amen01 - ale2] : Failed with error code 0xc0040814. [09:30:31.507] #1 : [amen01\amen01 - ale2] Error : Backup OK, but DBCC Skipped. [09:30:31.507] #2 : [amen01\amen01 - ale3] : Failed with error code 0xc0040814. [09:30:31.507] #2 : [amen01\amen01 - ale3] Error : Backup OK, but DBCC Skipped. [09:30:31.507] #3 : [amen01\amen01 - db4] : Failed with error code 0xc0040814. [09:30:31.507] #3 : [amen01\amen01 - db4] Error : Backup OK, but DBCC Skipped. [09:30:31.507] [09:30:31.507] *** SNAPMANAGER BACKUP JOB ENDED AT: [11-06-2008 09.30.31] [09:30:31.507] Unable to locate the database data file on the mounted disk drive. -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 1

RE: High CPU utilisation
by Davies,Matt 07 Nov '08

07 Nov '08

Jeff, The clients are experiencing some increase in latency, so I will investigate further, and see the problems occur during times of high utilisation. Thanks Matt -----Original Message----- From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] Sent: 06 November 2008 19:35 To: Davies,Matt Cc: toasters(a)mathworks.com Subject: Re: High CPU utilisation Matt: Are you experiencing client latency issues? A filer with a "high cpu state" is just that..and many have nothing to do with client protocol latency. CPU's doing what it's doing. It's not a windows/unix box. I dont see from this statit, that you have any actual performance issue, just "high cpu" which could be innumerable low priority tasks unique to your platform and OS. _____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You.

1 0

SMSQL and verification issues
by Milazzo Giacomo 06 Nov '08

06 Nov '08

Hi all, Up to now I've always set up SQL cluster with LUNs on drive letters and I've used a single stand alone SQL instance on the "passive" node of the cluster as verification server. Sincerely this is my first experience of SMSQL on a MS cluster using mount point and an external verification server. The scenario so is a SQL cluster using mount point instead of drive letters and an external verification server. We have the DB files on a LUN mounted as S:\DB01, the logs on another LUN mounted as S:\LOG01 and GLINKA0 as external verification server. Here follows the log. The backup is successfully done but when the verification starts something goes wrong: the snapshotted LUNs for DB and LOG are successfully mounted on Z: and Y: but SMSQL on verification does not find the db files a/o the log files looking for it on S:\DB01 (that is the path of the mount point!)... I hope this has nothing to do with capital or lowercase usage of paths J (we've S:\DB01 and S:\db01 on log...). From the verification server I can see the LUN mounted, I can browse them while are mounted and I can see the 'not found' files... Any idea? Thank you in advance, [09:28:45.992] *** VERIFY DATABASE AFTER BACKUP [09:28:45.992] Collecting verification information... [09:28:45.992] Getting database backup information from SnapInfo file... [09:28:45.992] Initializing SnapManager server on remote machine [GLINKA0]... [09:28:46.602] Mounting Snapshot [sqlsnap__amen01__recent] for Virtual Disk S:\DB01\ of Computer amen01 [09:29:15.180] This Snapshot is mounted as the drive [Z:]. [09:29:15.180] Mount Snapshot succeeded. [09:29:15.180] Mounting Snapshot [sqlsnap__amen01__recent] for Virtual Disk S:\LOG01\ of Computer amen01 [09:30:08.664] This Snapshot is mounted as the drive [Y:]. [09:30:08.664] Mount Snapshot succeeded. [09:30:08.664] Cannot find the data file in the mounted drive: [09:30:08.664] S:\db01\ale2.mdf [09:30:08.664] Dismounting Virtual Disk Z of SnapShot [sqlsnap__amen01__recent]... [09:30:25.429] Dismount Snapshot succeeded. [09:30:25.429] Dismounting Virtual Disk Y of SnapShot [sqlsnap__amen01__recent]... [09:30:31.476] Dismount Snapshot succeeded. [09:30:31.492] Unable to locate the database data file on the mounted disk drive. [09:30:31.492] Database verification information was not updated. [09:30:31.507] There is an error during database verification. [09:30:31.507] [09:30:31.507] **** FULL DATABASE BACKUP RESULT SUMMARY #1 **** [09:30:31.507] Backup Time: 11-06-2008_09.28.12 [09:30:31.507] Backup Group [#1]: [09:30:31.507] #1 : [amen01\amen01 - ale2] : Failed with error code 0xc0040814. [09:30:31.507] #1 : [amen01\amen01 - ale2] Error : Backup OK, but DBCC Skipped. [09:30:31.507] #2 : [amen01\amen01 - ale3] : Failed with error code 0xc0040814. [09:30:31.507] #2 : [amen01\amen01 - ale3] Error : Backup OK, but DBCC Skipped. [09:30:31.507] #3 : [amen01\amen01 - db4] : Failed with error code 0xc0040814. [09:30:31.507] #3 : [amen01\amen01 - db4] Error : Backup OK, but DBCC Skipped. [09:30:31.507] [09:30:31.507] *** SNAPMANAGER BACKUP JOB ENDED AT: [11-06-2008 09.30.31] [09:30:31.507] Unable to locate the database data file on the mounted disk drive.

2 2

High CPU utilisation
by Davies,Matt 06 Nov '08

06 Nov '08

Hi all, We are having a problem with a FAS270 that appears to be having high cpu utilisation issues. To be honest I have looked at sysstat and statit and I cannot see the problem. I would appreciate if someone could take a look at the below outputs and let me know what I'm missing. Thanks Matt ukfiler*> sysstat -i 3 CPU NFS CIFS iSCSI Net kB/s Disk kB/s iSCSI kB/s Cache in out read write in out age 85% 18 0 26 203 13 661 0 91 0 24 68% 9 1 50 283 23 692 0 221 9 24 92% 7 4 25 144 11 1643 2443 90 3 24 78% 12 1 74 345 21 618 0 198 0 24 67% 8 0 45 288 18 722 0 205 5 24 96% 13 1 32 236 14 1365 1708 151 1 24 81% 8 4 39 222 16 843 867 167 4 24 85% 8 0 33 443 10 1212 1456 118 0 24 99% 16 2 43 370 21 912 0 168 4 24 99% 14 16 23 219 26 1023 0 98 0 24 99% 12 0 36 585 39 2452 3781 465 18 24 ukfiler*> Hostname: ukfiler ID: 0084264545 Memory: 1022 MB NetApp Release 7.2.3: Thu Jul 5 10:06:16 PDT 2007 <6O> Start time: Wed Nov 5 22:45:03 GMT 2008 CPU Statistics 64.822501 time (seconds) 100 % 52.221602 system time 81 % 0.511694 rupt time 1 % (161581 rupts x 3 usec/rupt) 51.709908 non-rupt system time 80 % 77.423400 idle time 119 % 4.011144 time in CP 6 % 100 % 0.052061 rupt time in CP 1 % (12144 rupts x 4 usec/rupt) Multiprocessor Statistics (per second) cpu0 cpu1 total sk switches 6581.74 7585.82 14167.57 hard switches 1485.87 1560.68 3046.55 domain switches 72.75 65.01 137.76 CP rupts 125.45 61.89 187.34 nonCP rupts 1350.03 955.30 2305.33 IPI rupts 18.23 17.32 35.56 CP rupt usec 565.04 238.10 803.13 nonCP rupt usec 4342.69 2747.95 7090.64 idle 632999.86 561391.13 1194390.83 kahuna 334624.38 409797.24 744421.77 network 6697.98 8506.20 15204.18 storage 4193.90 5622.94 9816.84 exempt 3941.24 4036.10 7977.34 raid 7872.95 4627.33 12500.27 target 4409.87 2761.70 7171.57 netcache 0.00 0.00 0.00 netcache2 0.00 0.00 0.00 cifs 352.07 271.33 623.39 wafl_exempt 0.00 0.00 0.00 49.342358 seconds with one or more CPUs active ( 76%) 46.750469 seconds with one CPU active ( 72%) 2.591888 seconds with both CPUs active ( 4%) Domain Utilization By Exempt (per second) 0.00 idle 0.00 kahuna 0.00 network 0.00 storage 0.00 exempt 0.00 raid 0.00 target 0.00 netcache 0.00 netcache2 0.00 cifs 0.00 wafl_exempt CSMP Domain Switches (per second) From\To idle kahuna network storage exempt raid target netcache netcache2 cifs wafl_exem pt idle 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 0 kahuna 0.00 0.00 27.09 2.65 0.00 5.32 1.87 0.00 0.00 18.79 0.0 0 network 0.00 27.09 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.20 0.0 0 storage 0.00 2.65 0.00 0.00 0.00 12.96 0.00 0.00 0.00 0.00 0.0 0 exempt 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 0 raid 0.00 5.32 0.00 12.96 0.00 0.00 0.00 0.00 0.00 0.00 0.0 0 target 0.00 1.87 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 0 netcache 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 0 netcache2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 0 cifs 0.00 18.79 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 0 wafl_exempt 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0. 00 Miscellaneous Statistics (per second) 3046.55 hard context switches 10.38 NFS operations 1.42 CIFS operations 0.00 HTTP operations 0.00 NetCache URLs 0.00 streaming packets 1240.42 network KB received 100.32 network KB transmitted 655.39 disk KB read 1146.02 disk KB written 648.90 NVRAM KB written 0.00 nolog KB written 8.27 WAFL bufs given to clients 0.00 checksum cache hits ( 0%) 1.23 no checksum - partial buffer 0.00 FCP operations 74.48 iSCSI operations WAFL Statistics (per second) 15.94 name cache hits ( 95%) 0.86 name cache misses ( 5%) 529973.33 buf hash hits ( 100%) 1710.32 buf hash misses ( 0%) 516.44 inode cache hits ( 100%) 0.06 inode cache misses ( 0%) 262496.95 buf cache hits ( 100%) 19.65 buf cache misses ( 0%) 30.17 blocks read 67.00 blocks read-ahead 58.10 chains read-ahead 0.99 dummy reads 14.25 blocks speculative read-ahead 226.31 blocks written 2.27 stripes written 0.00 blocks over-written 0.09 wafl_timer generated CP 0.00 snapshot generated CP 0.00 wafl_avail_bufs generated CP 0.00 dirty_blk_cnt generated CP 0.00 full NV-log generated CP 0.00 back-to-back CP 0.00 flush generated CP 0.00 sync generated CP 0.00 wafl_avail_vbufs generated CP 0.00 deferred back-to-back CP 0.00 low datavecs generated CP 304.72 non-restart messages 4.98 IOWAIT suspends 133872 buffers RAID Statistics (per second) 40.91 xors 0.00 long dispatches [0] 0.00 long consumed [0] 0.00 long consumed hipri [0] 0.00 long low priority [0] 0.00 long high priority [0] 0.00 long monitor tics [0] 0.00 long monitor clears [0] 0.00 long dispatches [1] 0.00 long consumed [1] 0.00 long consumed hipri [1] 0.00 long low priority [1] 0.00 long high priority [1] 0.00 long monitor tics [1] 0.00 long monitor clears [1] 18 max batch 2.11 blocked mode xor 19.68 timed mode xor 0.05 fast adjustments 0.05 slow adjustments 0 avg batch start 0 avg stripe/msec 2.64 tetrises written 0.00 master tetrises 0.00 slave tetrises 29.70 stripes written 11.22 partial stripes 18.48 full stripes 226.68 blocks written 31.56 blocks read 1.13 1 blocks per stripe size 6 0.29 2 blocks per stripe size 6 0.17 3 blocks per stripe size 6 0.35 4 blocks per stripe size 6 1.80 5 blocks per stripe size 6 15.63 6 blocks per stripe size 6 1.11 1 blocks per stripe size 16 0.31 2 blocks per stripe size 16 0.32 3 blocks per stripe size 16 0.19 4 blocks per stripe size 16 0.09 5 blocks per stripe size 16 0.20 6 blocks per stripe size 16 0.05 7 blocks per stripe size 16 0.20 8 blocks per stripe size 16 0.12 9 blocks per stripe size 16 0.23 10 blocks per stripe size 16 0.23 11 blocks per stripe size 16 0.56 12 blocks per stripe size 16 0.83 13 blocks per stripe size 16 1.26 14 blocks per stripe size 16 1.76 15 blocks per stripe size 16 2.85 16 blocks per stripe size 16 Network Interface Statistics (per second) iface side bytes packets multicasts errors collisions pkt drops e0a recv 114768.96 92.82 0.00 0.00 0.00 xmit 193.85 1.43 0.05 0.00 0.00 e0b recv 521347.10 383.35 0.00 0.00 0.00 xmit 53015.11 280.33 0.14 0.00 0.00 vh recv 0.00 0.00 0.00 0.00 0.00 xmit 0.00 0.00 0.00 0.00 0.00 mtrunk1 recv 636116.06 476.18 0.00 0.00 0.00 xmit 53208.96 281.77 0.25 0.00 0.00 mtrunk1-1 recv 588.41 5.26 2.10 0.00 0.00 xmit 665.54 2.92 0.08 0.00 0.00 mtrunk1-21 recv 261620.02 204.87 0.00 0.00 0.00 xmit 22000.14 120.08 0.05 0.00 0.00 mtrunk1-22 recv 0.00 0.00 0.00 0.00 0.00 xmit 5.28 0.05 0.05 0.00 0.00 mtrunk1-23 recv 371871.00 264.20 0.02 0.00 0.00 xmit 26855.71 156.13 0.05 0.00 0.00 Disk Statistics (per second) ut% is the percent of time the disk was busy. xfers is the number of data-transfer commands issued per second. xfers = ureads + writes + cpreads + greads + gwrites chain is the average number of 4K blocks per command. usecs is the average disk round-trip time per 4K block. disk ut% xfers ureads--chain-usecs writes--chain-usecs cpreads-chain-usecs greads--chain-usecs gwrites-chain-usecs /aggr2/plex0/rg0: 0b.45 1 1.97 0.19 1.00 12333 1.10 9.42 988 0.69 5.07 768 0.00 .... . 0.00 .... . 0b.44 2 2.16 0.19 1.00 38167 1.28 8.35 925 0.69 5.07 838 0.00 .... . 0.00 .... . 0b.43 5 6.03 4.29 1.04 14107 1.13 6.84 1489 0.62 2.85 2430 0.00 .... . 0.00 .... . 0b.42 4 5.20 3.72 1.05 15565 0.88 8.00 1197 0.60 5.03 939 0.00 .... . 0.00 .... . 0b.41 4 5.09 3.76 1.01 14919 0.88 8.98 1184 0.45 4.03 1325 0.00 .... . 0.00 .... . 0b.40 5 5.28 4.09 1.08 13686 0.74 9.42 1210 0.45 5.28 1477 0.00 .... . 0.00 .... . 0b.39 5 5.54 4.18 1.08 15908 0.83 9.63 1142 0.52 4.44 1788 0.00 .... . 0.00 .... . 0b.38 4 5.45 3.90 1.00 17528 0.91 8.51 1327 0.63 3.56 1349 0.00 .... . 0.00 .... . 0b.37 4 5.29 3.72 1.07 16442 0.97 7.95 1359 0.60 4.23 1509 0.00 .... . 0.00 .... . 0b.36 4 5.01 3.50 1.01 13113 0.89 8.66 1371 0.62 4.18 1413 0.00 .... . 0.00 .... . 0b.32 5 5.54 4.03 1.36 11093 0.91 8.22 1433 0.60 3.92 1255 0.00 .... . 0.00 .... . 0b.17 4 5.06 3.76 1.01 13752 0.83 9.11 1268 0.46 4.60 1254 0.00 .... . 0.00 .... . 0b.33 5 5.51 3.90 1.02 14456 0.88 7.89 1553 0.73 4.02 1280 0.00 .... . 0.00 .... . 0b.18 4 5.51 3.79 1.19 12478 0.97 7.76 1591 0.74 3.71 1472 0.00 .... . 0.00 .... . 0b.34 5 5.51 3.89 1.12 13188 0.89 8.95 1301 0.73 3.62 1653 0.00 .... . 0.00 .... . 0b.19 4 5.04 3.56 1.07 11947 0.83 8.94 1308 0.65 3.50 2238 0.00 .... . 0.00 .... . 0b.35 4 4.74 3.33 1.14 12020 0.80 9.21 1353 0.60 4.26 1416 0.00 .... . 0.00 .... . 0b.20 4 5.32 3.89 1.01 13341 0.76 9.27 1352 0.68 3.86 1729 0.00 .... . 0.00 .... . /aggr1/plex0/rg0: 0b.24 2 2.39 0.19 1.00 13667 1.73 11.25 655 0.48 5.06 1140 0.00 .... . 0.00 .... . 0b.29 5 7.30 4.97 1.26 17742 1.71 10.48 666 0.62 3.45 1543 0.00 .... . 0.00 .... . 0b.26 4 6.34 4.37 1.28 13500 1.42 12.46 595 0.56 3.97 1427 0.00 .... . 0.00 .... . 0b.28 5 7.05 4.95 1.14 19218 1.50 11.82 695 0.60 3.44 1642 0.00 .... . 0.00 .... . 0b.27 7 6.20 4.26 1.05 19422 1.45 12.28 659 0.49 4.56 1000 0.00 .... . 0.00 .... . 0b.22 5 6.90 4.81 1.21 18814 1.53 11.51 835 0.56 3.81 1591 0.00 .... . 0.00 .... . 0b.21 4 6.57 4.37 1.11 18990 1.51 11.73 843 0.69 3.80 1655 0.00 .... . 0.00 .... . 0b.23 2 2.36 0.19 1.00 9667 1.70 11.42 677 0.48 5.06 1178 0.00 .... . 0.00 .... . Aggregate statistics: Minimum 1 1.97 0.19 0.74 0.45 0.00 0.00 Mean 4 5.15 3.44 1.11 0.59 0.00 0.00 Maximum 7 7.30 4.97 1.73 0.74 0.00 0.00 Spares and other disks: 0b.25 0 0.00 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . Spares and other disks: 0b.16 0 0.00 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . FCP Statistics (per second) 0.00 FCP Bytes recv 0.00 FCP Bytes sent 0.00 FCP ops iSCSI Statistics (per second) 516537.68 iSCSI Bytes recv 22866.13 iSCSI Bytes xmit 74.48 iSCSI ops Interrupt Statistics (per second) 1604.06 Clock (IRQ 5) 35.51 IPI (IRQ 8) 35.51 IPI (IRQ 9) 160.84 FCAL (IRQ 23) 259.37 SB MAC (IRQ 25) 41.22 SB MAC (IRQ 26) 35.56 IPI 2172.07 total Data Mover Statistics (per second) 627.05 total dma transfer KB 408.55 dma descriptors 82.58 dma desc wait count 753.86 total dma transfer KB 523.52 dma descriptors 112.63 dma desc wait count 0.00 total dma transfer KB 0.00 dma descriptors 0.00 dma desc wait count 0.00 total dma transfer KB 0.00 dma descriptors 0.00 dma desc wait count ____________________________ Matt Davies Director of International IT Operations General Atlantic 83 Pall Mall London SW1Y 5ES Tel: +44 207 484 3203 Fax: +44 207 484 2803 Mobile: +44 777 559 4265 ____________________________ _____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You.

5 4

SMSharepoint 1.1.1 & SMSQL 5.0
by Alexander Schalek 06 Nov '08

06 Nov '08

Hi all, has anyone sucessfully installed SM Sharepoint 1.1.1 in a SMSQL 5.0 environment? thanks in advance! alex -- Alexander Schalek, Technical Services / IT-Infrastruktur Bacher Systems EDV GmbH FN 54202i, Handelsgericht Wien Clemens-Holzmeister-Strasse 4 A-1100 Wien, Business Park Vienna, Austria phone: +43 (1) 60 126-34 | fax: -4 e-mail: as(a)bacher.at<mailto:as@bacher.at> | web: www.bacher.at<http://www.bacher.at/> -- unsere nächsten Veranstaltungen: NetApp Innovation 2008: http://www.netapp-innovation.at<http://www.netapp-innovation.at/>

2 2

RE: High CPU utilisation
by Davies,Matt 06 Nov '08

06 Nov '08

Nils, 1, yes it is both a source and destination for snapmirror, there is no snapvault 2, see below. ukfiler*> wafl scan status Volume CIFS_UK: Scan id Type of scan progress 3 active bitmap rearrangement fbn 1605 of 2230 w/ max_chain_len 3 191730 container block reclamation block 2042 of 2230 Volume root: Scan id Type of scan progress 5 active bitmap rearrangement fbn 63 of 107 w/ max_chain_len 3 191636 container block reclamation block 64 of 107 Volume UKEXCHDB: Scan id Type of scan progress 8 active bitmap rearrangement fbn 138 of 713 w/ max_chain_len 3 Volume UKEXCHLOGS: Scan id Type of scan progress 10 active bitmap rearrangement fbn 369 of 401 w/ max_chain_len 3 191608 container block reclamation block 391 of 401 Volume UKVMWARE: Scan id Type of scan progress 12 active bitmap rearrangement fbn 1538 of 4461 w/ max_chain_len 3 Volume DUEXCHLOGS: Scan id Type of scan progress 191713 container block reclamation block 879 of 892 Volume UKVIRTUALCENTRE: Scan id Type of scan progress 16 active bitmap rearrangement fbn 197 of 1115 w/ max_chain_len 3 Volume UKVMWARE1: Scan id Type of scan progress 18 active bitmap rearrangement fbn 4215 of 4461 w/ max_chain_len 3 Volume UKVMWARENFS: Scan id Type of scan progress 21 active bitmap rearrangement fbn 1019 of 1784 w/ max_chain_len 3 Volume TESTUKEXCHLOGS: Scan id Type of scan progress 191708 container block reclamation block 393 of 401 Volume UKEXCH3DB: Scan id Type of scan progress 152073 active bitmap rearrangement fbn 548 of 571 w/ max_chain_len 3 191729 container block reclamation block 356 of 571 Volume vol1: Scan id Type of scan progress 191630 container block reclamation block 0 of 0 Volume UKEXCH3LOGS: Scan id Type of scan progress 152075 active bitmap rearrangement fbn 29 of 321 w/ max_chain_len 3 191728 container block reclamation block 195 of 321 Thanks Matt -----Original Message----- From: Nils Vogels [mailto:bacardicoke@gmail.com] Sent: 06 November 2008 09:29 To: Davies,Matt Subject: Re: High CPU utilisation Couple of questions .. 1) Do you have snapvault/snapmirror running? 2) What does "wafl scan status" tell you? Greetings, Nils On Thu, Nov 6, 2008 at 10:09 AM, Davies,Matt <MDAVIES(a)generalatlantic.com> wrote: > Hi all, > > We are having a problem with a FAS270 that appears to be having high cpu utilisation issues. > > To be honest I have looked at sysstat and statit and I cannot see the problem. I would appreciate if someone could take a look at the below outputs and let me know what I'm missing. > > Thanks > > Matt > > ukfiler*> sysstat -i 3 > CPU NFS CIFS iSCSI Net kB/s Disk kB/s iSCSI kB/s Cache > in out read write in out age > 85% 18 0 26 203 13 661 0 91 0 24 > 68% 9 1 50 283 23 692 0 221 9 24 > 92% 7 4 25 144 11 1643 2443 90 3 24 > 78% 12 1 74 345 21 618 0 198 0 24 > 67% 8 0 45 288 18 722 0 205 5 24 > 96% 13 1 32 236 14 1365 1708 151 1 24 > 81% 8 4 39 222 16 843 867 167 4 24 > 85% 8 0 33 443 10 1212 1456 118 0 24 > 99% 16 2 43 370 21 912 0 168 4 24 > 99% 14 16 23 219 26 1023 0 98 0 24 > 99% 12 0 36 585 39 2452 3781 465 18 24 > ukfiler*> > > Hostname: ukfiler ID: 0084264545 Memory: 1022 MB > NetApp Release 7.2.3: Thu Jul 5 10:06:16 PDT 2007 > <6O> > Start time: Wed Nov 5 22:45:03 GMT 2008 > > CPU Statistics > 64.822501 time (seconds) 100 % > 52.221602 system time 81 % > 0.511694 rupt time 1 % (161581 rupts x 3 usec/rupt) > 51.709908 non-rupt system time 80 % > 77.423400 idle time 119 % > > 4.011144 time in CP 6 % 100 % > 0.052061 rupt time in CP 1 % (12144 rupts x 4 usec/rupt) > > Multiprocessor Statistics (per second) > cpu0 cpu1 total > sk switches 6581.74 7585.82 14167.57 > hard switches 1485.87 1560.68 3046.55 > domain switches 72.75 65.01 137.76 > CP rupts 125.45 61.89 187.34 > nonCP rupts 1350.03 955.30 2305.33 > IPI rupts 18.23 17.32 35.56 > > CP rupt usec 565.04 238.10 803.13 > nonCP rupt usec 4342.69 2747.95 7090.64 > idle 632999.86 561391.13 1194390.83 > kahuna 334624.38 409797.24 744421.77 > network 6697.98 8506.20 15204.18 > storage 4193.90 5622.94 9816.84 > exempt 3941.24 4036.10 7977.34 > raid 7872.95 4627.33 12500.27 > target 4409.87 2761.70 7171.57 > netcache 0.00 0.00 0.00 > netcache2 0.00 0.00 0.00 > cifs 352.07 271.33 623.39 > wafl_exempt 0.00 0.00 0.00 > > 49.342358 seconds with one or more CPUs active ( 76%) > > 46.750469 seconds with one CPU active ( 72%) > 2.591888 seconds with both CPUs active ( 4%) > > Domain Utilization By Exempt (per second) > 0.00 idle 0.00 kahuna > 0.00 network 0.00 storage > 0.00 exempt 0.00 raid > 0.00 target 0.00 netcache > 0.00 netcache2 0.00 cifs > 0.00 wafl_exempt > > > CSMP Domain Switches (per second) > From\To idle kahuna network storage exempt raid target netcache netcache2 cifs wafl_exem > pt > idle 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 > 0 > kahuna 0.00 0.00 27.09 2.65 0.00 5.32 1.87 0.00 0.00 18.79 0.0 > 0 > network 0.00 27.09 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.20 0.0 > 0 > storage 0.00 2.65 0.00 0.00 0.00 12.96 0.00 0.00 0.00 0.00 0.0 > 0 > exempt 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 > 0 > raid 0.00 5.32 0.00 12.96 0.00 0.00 0.00 0.00 0.00 0.00 0.0 > 0 > target 0.00 1.87 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 > 0 > netcache 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 > 0 > netcache2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 > 0 > cifs 0.00 18.79 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0 > 0 > wafl_exempt 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0. > 00 > > Miscellaneous Statistics (per second) > 3046.55 hard context switches 10.38 NFS operations > 1.42 CIFS operations 0.00 HTTP operations > 0.00 NetCache URLs 0.00 streaming packets > 1240.42 network KB received 100.32 network KB transmitted > 655.39 disk KB read 1146.02 disk KB written > 648.90 NVRAM KB written 0.00 nolog KB written > 8.27 WAFL bufs given to clients 0.00 checksum cache hits ( 0%) > 1.23 no checksum - partial buffer 0.00 FCP operations > 74.48 iSCSI operations > > WAFL Statistics (per second) > 15.94 name cache hits ( 95%) 0.86 name cache misses ( 5%) > 529973.33 buf hash hits ( 100%) 1710.32 buf hash misses ( 0%) > 516.44 inode cache hits ( 100%) 0.06 inode cache misses ( 0%) > 262496.95 buf cache hits ( 100%) 19.65 buf cache misses ( 0%) > 30.17 blocks read 67.00 blocks read-ahead > 58.10 chains read-ahead 0.99 dummy reads > 14.25 blocks speculative read-ahead 226.31 blocks written > 2.27 stripes written 0.00 blocks over-written > 0.09 wafl_timer generated CP 0.00 snapshot generated CP > 0.00 wafl_avail_bufs generated CP 0.00 dirty_blk_cnt generated CP > 0.00 full NV-log generated CP 0.00 back-to-back CP > 0.00 flush generated CP 0.00 sync generated CP > 0.00 wafl_avail_vbufs generated CP 0.00 deferred back-to-back CP > 0.00 low datavecs generated CP 304.72 non-restart messages > 4.98 IOWAIT suspends 133872 buffers > > RAID Statistics (per second) > 40.91 xors 0.00 long dispatches [0] > 0.00 long consumed [0] 0.00 long consumed hipri [0] > 0.00 long low priority [0] 0.00 long high priority [0] > 0.00 long monitor tics [0] 0.00 long monitor clears [0] > 0.00 long dispatches [1] 0.00 long consumed [1] > 0.00 long consumed hipri [1] 0.00 long low priority [1] > 0.00 long high priority [1] 0.00 long monitor tics [1] > 0.00 long monitor clears [1] 18 max batch > 2.11 blocked mode xor 19.68 timed mode xor > 0.05 fast adjustments 0.05 slow adjustments > 0 avg batch start 0 avg stripe/msec > 2.64 tetrises written 0.00 master tetrises > 0.00 slave tetrises 29.70 stripes written > 11.22 partial stripes 18.48 full stripes > 226.68 blocks written 31.56 blocks read > 1.13 1 blocks per stripe size 6 0.29 2 blocks per stripe size 6 > 0.17 3 blocks per stripe size 6 0.35 4 blocks per stripe size 6 > 1.80 5 blocks per stripe size 6 15.63 6 blocks per stripe size 6 > 1.11 1 blocks per stripe size 16 0.31 2 blocks per stripe size 16 > 0.32 3 blocks per stripe size 16 0.19 4 blocks per stripe size 16 > 0.09 5 blocks per stripe size 16 0.20 6 blocks per stripe size 16 > 0.05 7 blocks per stripe size 16 0.20 8 blocks per stripe size 16 > 0.12 9 blocks per stripe size 16 0.23 10 blocks per stripe size 16 > 0.23 11 blocks per stripe size 16 0.56 12 blocks per stripe size 16 > 0.83 13 blocks per stripe size 16 1.26 14 blocks per stripe size 16 > 1.76 15 blocks per stripe size 16 2.85 16 blocks per stripe size 16 > > Network Interface Statistics (per second) > iface side bytes packets multicasts errors collisions pkt drops > e0a recv 114768.96 92.82 0.00 0.00 0.00 > xmit 193.85 1.43 0.05 0.00 0.00 > e0b recv 521347.10 383.35 0.00 0.00 0.00 > xmit 53015.11 280.33 0.14 0.00 0.00 > vh recv 0.00 0.00 0.00 0.00 0.00 > xmit 0.00 0.00 0.00 0.00 0.00 > mtrunk1 recv 636116.06 476.18 0.00 0.00 0.00 > xmit 53208.96 281.77 0.25 0.00 0.00 > mtrunk1-1 recv 588.41 5.26 2.10 0.00 0.00 > xmit 665.54 2.92 0.08 0.00 0.00 > mtrunk1-21 recv 261620.02 204.87 0.00 0.00 0.00 > xmit 22000.14 120.08 0.05 0.00 0.00 > mtrunk1-22 recv 0.00 0.00 0.00 0.00 0.00 > xmit 5.28 0.05 0.05 0.00 0.00 > mtrunk1-23 recv 371871.00 264.20 0.02 0.00 0.00 > xmit 26855.71 156.13 0.05 0.00 0.00 > > Disk Statistics (per second) > ut% is the percent of time the disk was busy. > xfers is the number of data-transfer commands issued per second. > xfers = ureads + writes + cpreads + greads + gwrites > chain is the average number of 4K blocks per command. > usecs is the average disk round-trip time per 4K block. > > disk ut% xfers ureads--chain-usecs writes--chain-usecs cpreads-chain-usecs greads--chain-usecs gwrites-chain-usecs > /aggr2/plex0/rg0: > 0b.45 1 1.97 0.19 1.00 12333 1.10 9.42 988 0.69 5.07 768 0.00 .... . 0.00 .... . > 0b.44 2 2.16 0.19 1.00 38167 1.28 8.35 925 0.69 5.07 838 0.00 .... . 0.00 .... . > 0b.43 5 6.03 4.29 1.04 14107 1.13 6.84 1489 0.62 2.85 2430 0.00 .... . 0.00 .... . > 0b.42 4 5.20 3.72 1.05 15565 0.88 8.00 1197 0.60 5.03 939 0.00 .... . 0.00 .... . > 0b.41 4 5.09 3.76 1.01 14919 0.88 8.98 1184 0.45 4.03 1325 0.00 .... . 0.00 .... . > 0b.40 5 5.28 4.09 1.08 13686 0.74 9.42 1210 0.45 5.28 1477 0.00 .... . 0.00 .... . > 0b.39 5 5.54 4.18 1.08 15908 0.83 9.63 1142 0.52 4.44 1788 0.00 .... . 0.00 .... . > 0b.38 4 5.45 3.90 1.00 17528 0.91 8.51 1327 0.63 3.56 1349 0.00 .... . 0.00 .... . > 0b.37 4 5.29 3.72 1.07 16442 0.97 7.95 1359 0.60 4.23 1509 0.00 .... . 0.00 .... . > 0b.36 4 5.01 3.50 1.01 13113 0.89 8.66 1371 0.62 4.18 1413 0.00 .... . 0.00 .... . > 0b.32 5 5.54 4.03 1.36 11093 0.91 8.22 1433 0.60 3.92 1255 0.00 .... . 0.00 .... . > 0b.17 4 5.06 3.76 1.01 13752 0.83 9.11 1268 0.46 4.60 1254 0.00 .... . 0.00 .... . > 0b.33 5 5.51 3.90 1.02 14456 0.88 7.89 1553 0.73 4.02 1280 0.00 .... . 0.00 .... . > 0b.18 4 5.51 3.79 1.19 12478 0.97 7.76 1591 0.74 3.71 1472 0.00 .... . 0.00 .... . > 0b.34 5 5.51 3.89 1.12 13188 0.89 8.95 1301 0.73 3.62 1653 0.00 .... . 0.00 .... . > 0b.19 4 5.04 3.56 1.07 11947 0.83 8.94 1308 0.65 3.50 2238 0.00 .... . 0.00 .... . > 0b.35 4 4.74 3.33 1.14 12020 0.80 9.21 1353 0.60 4.26 1416 0.00 .... . 0.00 .... . > 0b.20 4 5.32 3.89 1.01 13341 0.76 9.27 1352 0.68 3.86 1729 0.00 .... . 0.00 .... . > /aggr1/plex0/rg0: > 0b.24 2 2.39 0.19 1.00 13667 1.73 11.25 655 0.48 5.06 1140 0.00 .... . 0.00 .... . > 0b.29 5 7.30 4.97 1.26 17742 1.71 10.48 666 0.62 3.45 1543 0.00 .... . 0.00 .... . > 0b.26 4 6.34 4.37 1.28 13500 1.42 12.46 595 0.56 3.97 1427 0.00 .... . 0.00 .... . > 0b.28 5 7.05 4.95 1.14 19218 1.50 11.82 695 0.60 3.44 1642 0.00 .... . 0.00 .... . > 0b.27 7 6.20 4.26 1.05 19422 1.45 12.28 659 0.49 4.56 1000 0.00 .... . 0.00 .... . > 0b.22 5 6.90 4.81 1.21 18814 1.53 11.51 835 0.56 3.81 1591 0.00 .... . 0.00 .... . > 0b.21 4 6.57 4.37 1.11 18990 1.51 11.73 843 0.69 3.80 1655 0.00 .... . 0.00 .... . > 0b.23 2 2.36 0.19 1.00 9667 1.70 11.42 677 0.48 5.06 1178 0.00 .... . 0.00 .... . > > Aggregate statistics: > Minimum 1 1.97 0.19 0.74 0.45 0.00 0.00 > Mean 4 5.15 3.44 1.11 0.59 0.00 0.00 > Maximum 7 7.30 4.97 1.73 0.74 0.00 0.00 > > Spares and other disks: > 0b.25 0 0.00 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . > > Spares and other disks: > 0b.16 0 0.00 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . > > FCP Statistics (per second) > 0.00 FCP Bytes recv 0.00 FCP Bytes sent > 0.00 FCP ops > > iSCSI Statistics (per second) > 516537.68 iSCSI Bytes recv 22866.13 iSCSI Bytes xmit > 74.48 iSCSI ops > > Interrupt Statistics (per second) > 1604.06 Clock (IRQ 5) 35.51 IPI (IRQ 8) > 35.51 IPI (IRQ 9) 160.84 FCAL (IRQ 23) > 259.37 SB MAC (IRQ 25) 41.22 SB MAC (IRQ 26) > 35.56 IPI 2172.07 total > > Data Mover Statistics (per second) > 627.05 total dma transfer KB 408.55 dma descriptors > 82.58 dma desc wait count 753.86 total dma transfer KB > 523.52 dma descriptors 112.63 dma desc wait count > 0.00 total dma transfer KB 0.00 dma descriptors > 0.00 dma desc wait count 0.00 total dma transfer KB > 0.00 dma descriptors 0.00 dma desc wait count > > ____________________________ > Matt Davies > Director of International IT Operations > General Atlantic > 83 Pall Mall > London > SW1Y 5ES > > Tel: +44 207 484 3203 > Fax: +44 207 484 2803 > Mobile: +44 777 559 4265 > ____________________________ > > > > > _____________________________________________________________ > This e-mail (including all attachments) is confidential and may be privileged. > It is for the exclusive use of the addressee only. If you are not the addressee, > you are hereby notified that any dissemination of this communication is strictly > prohibited. If you have received this communication in error, please erase all > copies of the message and its attachments and notify us immediately at > help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You. > > -- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.

1 0

RE: Is the list still active
by Davies,Matt 06 Nov '08

06 Nov '08

I will re post and see what happens.... Thanks Matt -----Original Message----- From: De Wit Tom (Consultant) [mailto:tom.de.wit@consultant.volvo.com] Sent: 06 November 2008 09:06 To: Davies,Matt; toasters(a)mathworks.com Subject: RE: Is the list still active Well it works now ;-) Yes, the list is still active. Grtz, Tom -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Davies,Matt Sent: donderdag 6 november 2008 9:45 To: toasters(a)mathworks.com Subject: Is the list still active Have been trying to post a message but it does not appear to be working. _____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You.

1 0

Is the list still active
by Davies,Matt 06 Nov '08

06 Nov '08

Have been trying to post a message but it does not appear to be working. _____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You.

1 0

TR-3428 & Cross-stack Etherchannel
by Carl Howell 04 Nov '08

04 Nov '08

For those of you that are doing LACP/cross-stack Etherchannel in your ESX environments, like the example in section 6.8 on page 40 of TR-3428, what switches are you using? If you are doing LACP across Cisco 6500's, what SUP's are you using? Thanks, --Carl

12 15

SV: Brief outages on the filer?
by Karlsson Ulf Ibrahim :ULK 04 Nov '08

04 Nov '08

Maybe this from http://media.netapp.com/documents/tr-3428.pdf (Netapp+VMware storage best practices) When using VMware snapshots (VMsnaps) with NFS Datastores a condition exists where I/O to the VM is suspended while VMsnaps are being deleted (or more technically speaking the process of committing the redo logs to the VMDK files occur). This issue is experienced with any VMware technology that leverages VMsnaps such as VMware Consolidated Backup, Storage VMotion, Scalable Virtual Images, etc. and SnapManager for Virtual Infrastructure from NetApp. VMware has identified this behavior as a bug (SR195302591), and has released patch ESX350-200808401-BG which addresses this bug. At present time, this patch applies to ESX version 3.5, updates 1 and 2 only. If you plan on leveraging any of the applications that require the VMsnap process please apply this patch, and complete its installation requirements, on the ESX servers in your environment. If you are using scripts in order to take on disk snapshot backups and are unable to upgrade your systems, then VMware and NetApp recommend that you discontinue the use of the VMsnap process prior to executing the NetApp snapshot. /Uffe -----Ursprungligt meddelande----- Från: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] För Glenn Walker Skickat: den 3 november 2008 20:03 Till: Page, Jeremy; toasters(a)mathworks.com Ämne: RE: Brief outages on the filer? Any way you can predict when it will happen? Sysstat (or better yet, perfstat) would be of help here. Something I've noticed on my infrastructure: VMWare over NFS (unsure about other protocols) will have huge spikes where they write lots of data in a quick burst - happens only a few times a day on relatively quiet systems, but I can definitely see a spike on the filer. Perhaps you have the same thing going, just a SWAG... The impact on our side is not really felt - but the filer does go into back2back CPs from the massive spike (200MB/s - 350MB/s in a short window) and that could manifest itself as 'poor disk response time'. In our case, we're running VMWare over NFS and Exchange over iSCSI on the same filers, but no one is really complaining when the 'events' happen. Just something I've noticed for a while. FAS6070 and the busy time is recorded around 6000 NFS IOPS. That said, we did a stress test with about 25 guests running IOMeter and were able to push 15000 NFS OPS on node 1, 10000 NFS OPS on node 2 (a combined 400MB/s write, 300MB/s read) without any sort of reported performance problems. ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Monday, November 03, 2008 11:02 AM To: toasters(a)mathworks.com Subject: Brief outages on the filer? I am seeing brief outages where my VMs (NFS as the back end protocol) and SQL LUNs (FC) both complain of poor disk response time at the same time. I don't think it can be the infrastructure since one is IP and the other FC. The LUNs are on a different set of spindles/different aggr then the NFS volumes as well, so I don't think it's a disk bottleneck. I'm on a 3070 and rarely do we hit 3500 IOPS (and 90+% of that out of cache) or go above 40% for the busiest CPU (normally we're in the 15-25% range) so I am not sure what's going on here, any suggestions on how to troubleshoot it? We're running 7.2.4, I want to wait for 7.3.1 to upgrade since we are using NFS for VMware and there are several fixes that will be beneficial to us. Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

3 5

RE: Data OnTap 7.2.6
by Darragh, Stephen J (US SSA) 03 Nov '08

03 Nov '08

Hello, You mention you believe it was GA at one point, and I don't believe that is correct. It used to be the case, but at some point, they determined that if the base release was GD, then subsiqent released are auto-majically placed into GD status. This has caused us problems and I hope others chime in to see if NetApp will go back to the old release cycle of every version being GA before going to GD. Stephen Darragh BAE Systems IT Merrimack NH -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Kevin Sheen Sent: Thursday, October 30, 2008 9:04 PM To: Jack Lyons; toasters(a)mathworks.com Subject: Re: Data OnTap 7.2.6 We upgraded a pair of clustered 3070's and a 3020 last Saturday. We do a small amount of CIFS, more NFS and lots of LUNs. We haven't had any issues. All of the hosts connected to the clustered 3070's are multipathed except for one. good luck with the issues, Kevin At 07:17 PM 10/30/2008, Jack Lyons wrote: Does NetApp still publish the number of appliances running different version of Data OnTap? We just upgraded to 7.2.6 on Sunday and we have had two (and possibly a third) panics causing failover on 1 of the 4 filers. Failover went smoothly for the most part (I bet the app team that didn't want to spend the money multipathing software / hba's will be singing another tune tomorrow) but both panics didn't create complete core dumps. We are working on the case with NetApp support but want to see what other people were seeing about 7.2.6. 7.2.6 went GD recently and I assume it was GA for awhile before that, but I can't figure release dates or the number of appliances running the different versions of Data OnTap. Thanks Jack p.s. why did we upgrade? http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=281669 is the bug we are hitting...in addition to: http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=253517 http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=256975 http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=271864

3 2

Maximum number of SnapVaul/SnapMirrort relations that can be defined on a filer
by Filip Sneppe 29 Oct '08

29 Oct '08

Hi, I know about the maximum number of active SV/SM transfers one can have on the different filer models, but are there any limits to the number of relations that can be defined on a filer ? I've seen filers/nearstores with a couple of hundred SV relations, and they all looked fine to me, but that's it. Is it possible to define thousands of SV relations on one filer ? Apart from the transfer concurrency problems one is bound to run into, are there any other issues one should know about ? Thanks in advance, Filip

1 0

VARs
by Nicholas Bernstein 28 Oct '08

28 Oct '08

Could someone point me to a list of Netapp VARs? I remember seeing a page somewhere but couldn't seem to find a way to get google to point me in the right direction. Thanks in advance, Nick -- Nicholas Bernstein Technologist, Consultant, Instructor http://nicholasbernstein.com

2 2

Quick question about ASIS
by Page, Jeremy 22 Oct '08

22 Oct '08

So here's what my filer looks like: gvr-array02*> sis status Path State Status Progress /vol/nfs2 Enabled Active 2318 GB Searched /vol/nfs3 Enabled Active 3648 GB Searched /vol/nfs4 Enabled Idle Idle for 143:01:40 /vol/nfs6 Enabled Idle Idle for 05:27:23 /vol/nfs7 Enabled Active 28 GB (11%) Done /vol/shares Enabled Idle Idle for 82:53:20 /vol/vmware Enabled Idle Idle for 47:04:42 The weird thing is none of my NFS volumes are more then a TB in size, is it looking through the whole aggr? If so, why does the job run on a per volume level? Please be advised that this email may be a confidential communication and may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by e-mail by replying to the sender and by telephone (call us collect at 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement; provided, that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

2 1

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