toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

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

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