toasters February 2008

toasters@lists.teaparty.net

76 participants
52 discussions

UnionFS on NetApp
by Sebastien Campion 11 Feb '08

11 Feb '08

Hi, i would like to known if it's possible to merge volume like unionfs merge mount point to increase volume size ? Is it possible ? I'm using a Data ONTAP Release 7.2.2. Sébastien.

1 0

IBM SAN Volume Controller
by David McWilliams 11 Feb '08

11 Feb '08

I'm currently on 6.5.6. Does anyone know what version of ONTAP support the IBM SAN Volume Controller? -- Sláinte, David Get a safer, faster, better web browser @ http://www.mozilla.org/products/firefox/

2 1

Determine the last time a volume or lun has been accessed?
by romeotheriault 08 Feb '08

08 Feb '08

Is there a way to determine the last time a volume or Lun has been accessed? Thank you, Romeo -- View this message in context: http://www.nabble.com/Determine-the-last-time-a-volume-or-lun-has-been-acce… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

1 0

How to increase SnapManager for Exchange timeout for SnapMirror transfer start.
by Borzenkov, Andrey 07 Feb '08

07 Feb '08

We hit somewhat interesting problem with SME 4.0. After start of backup with verification on remote destination SME waits for transfer to start and after 3 minutes times out and fails verification. Verification for the second LUN on the same volume started later runs OK (including waiting for transfer to complete). I.e. [14:42:50.963] ------------ SnapMirror Update --------------- [14:42:50.963] SnapMirror is going to update the following Exchange Disks: [14:42:50.963] E [14:42:50.963] F [14:42:50.963] H [14:42:50.963] e [14:42:51.072] Requesting SnapMirror update transfer for LUN E. [14:42:55.025] Request for SnapMirror update transfer of LUN E sent successfully. [14:42:55.025] Requesting SnapMirror update transfer for LUN F. [14:43:11.541] Request for SnapMirror update transfer of LUN F sent successfully. [14:43:11.541] ***BACKUP VERIFICATION: SG2 [14:43:11.557] Start to verify the database in snapshot... [14:43:22.417] Initializing SnapManager server on remote machine yyy... [14:43:29.651] Mounting Snapshot [exchsnap__xxx__recent] for LUN H created from Computer xxx [14:43:29.714] Using default mount point directory [C:\Program Files\NetApp\SnapManager for Exchange\SnapMgrMountPoint] [14:43:29.714] SnapShot exchsnap__xxx__recent in the selected destination volume xxx:sm_EX_DB will be used to mount a LUN. [14:43:31.557] Starting monitoring SnapMirror update progress... [14:43:31.714] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 0 kbytes. [14:44:01.870] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 0 kbytes. [14:44:32.027] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 0 kbytes. [14:45:02.200] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 0 kbytes. [14:45:32.450] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 0 kbytes. [14:46:01.560] SnapMirror transfer progress update progress did not returned within a designated amount of time. SnapManager canceled the SnapDrive operation to mount a LUN on the SnapMirror destination volume. And later [14:46:35.717] ***BACKUP VERIFICATION: SG1 [14:46:35.717] Start to verify the database in snapshot... [14:46:45.249] Initializing SnapManager server on remote machine yyy... [14:46:52.389] Mounting Snapshot [exchsnap__xxx__recent] for LUN E created from Computer yyy [14:46:52.436] Using default mount point directory [C:\Program Files\NetApp\SnapManager for Exchange\SnapMgrMountPoint] [14:46:52.436] SnapShot exchsnap__xxx__recent in the selected destination volume xxx:sm_EX_DB will be used to mount a LUN. [14:46:55.405] Starting monitoring SnapMirror update progress... [14:46:55.561] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 0 kbytes. [14:47:25.718] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 0 kbytes. [14:47:55.953] SnapMirror update progress received for destination volume xxxt:sm_EX_DB. SnapMirror has transferred 8 kbytes. [14:48:26.188] SnapMirror update progress received for destination volume xxx:sm_EX_DB. SnapMirror has transferred 8 kbytes. After that this runs to completion. Apparently transfer needs ca. 5 minutes to actually start; is it possible to increase SME wait time in this case? С уважением / With best regards / Mit freundlichen Grüβen --- Andrey Borzenkov Senior system engineer

1 0

getting Used space on a newly cloned filer volume
by Anna M 06 Feb '08

06 Feb '08

If we fetch a volume's space details (using df) on the filer immediately after some data is copied/changed on the volume then we do not get accurate results. Similarly, in cases where we fetch the volume's space details immediately after its creation from a snapshot of parent volume, we don't get valid results. It takes a long time for the "used space" to settle down to a single value depending on the amount of data. For eg : For a volume of size 10G with used space 9G, the new volume that is created takes around 13 minutes to settle down to a consistent used space value. The pattern that is usually observed is - used_space will start from a very high value then it will keep getting lesser till a point in time and after that it shoots up again. Steps to reproduce this issue: Steps to reproduce. 1. Create a empty volume of size say 10G. 2. Copy data of size 9G. (Used space is 9G). 3. Create a snapshot of this volume. 4. Create a new flexclone using this snapshot and measure space stats of the new volume repeatedly with some time lag in between. The script I had : rsh <filer> vol clone create test_to_check -b <volname> <Snapname> rsh <filer> df -k test_to_check sleep 1; rsh <filer> df -k test_to_check sleep 1; rsh <filer> df -k test_to_check sleep 1; rsh <filer> df -k test_to_check sleep 1; rsh <filer> df -k test_to_check In this case, for a parent volume of size 10G with 9G of used space, it takes around 13min for the used space to settle down for the new volume. While cloning a volume of size 310GB, i saw that used_space fluctuted from 385GB -> 310 GB before it started shooting up again. How can I find out the actual used space on this newly created volume? Any insight in to this issue will be really useful. -- View this message in context: http://www.nabble.com/getting-Used-space-on-a-newly-cloned-filer-volume-tp1… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

1 0

Deleting many large files spikes filer CPU
by Stephen C. Losen 06 Feb '08

06 Feb '08

We have a fairly heavily loaded FAS960c pair that contains storage for our University wide email system. Most of the email storage is NFS files with the email servers running Unix and Communigate Pro. We are transitioning to MS Exchange, so these filers also have some FC SAN LUNs for our emerging Exchange service. The other day we cleaned up about a hundred NFS email inboxes, average size about 100M, but a few were approaching 1G. We removed the files on a NFS client and immediately after the rm command returned, we experienced a serious performance problem on the 960s. sysstat indicated that the CPU was pegged at near 100% while all I/O throughput (network, disk, FC SAN) and all file ops (NFS, FCP) dropped to almost nothing. Something grabbed the filer CPU for a minute or two which seriously impacted all of our email servers. We had to restart them all. I suspect that the CPU load was caused by some processing having to do with recovering disk blocks freed by the file deletes. But no blocks were actually freed because the volume had snapshots that were newer than the deleted files. Perhaps the number of snapshots (41) was a factor. I opened a case with netapp on this, but repeating the problem will have dire consequences on our production email systems, so we can't send them performance metrics. I checked bugs online on NOW and didn't find anything that seemed to apply that wasn't marked fixed. I did see a very old bug (4157) first fixed in DOT 5.1, where WAFL would deadlock if many large files were deleted all at once. I was just curious if anyone else has run into anything like this. We are running DOT 7.2.3. In the future when we delete a lot of big files, we'll do them one at a time, with sleeps in between. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

7 6

snapmirror job "hung" and abort won't
by R.P. Aditya 06 Feb '08

06 Feb '08

I have a filer pair where the source filer shows this: Snapmirror is on. Source Destination State Lag Status boxcar:ctfs2008 flatcar:ctfs2008 Source 00:04:43 Idle boxcar:orabackup flatcar:orabackup Source - Aborting boxcar:watsadmin flatcar:watsadmin Source 01:04:45 Transferring (1352 MB done) and the destination filer, after various attempts to abort a job on the source/destination shows: Snapmirror is on. Source Destination State Lag Status boxcar-vif0:ctfs2008 flatcar:ctfs2008 Snapmirrored 00:04:29 Idle boxcar-vif0:orabackup flatcar:orabackup Broken-off 150:34:31 Idle boxcar-vif0:watsadmin flatcar:watsadmin Snapmirrored 01:04:31 Transferring (1566 MB done) the boxcar:orabackup to flatcar:orabackup job is in a bad state and sending snapmirror abort -h flatcar:orabackup on the source filer doesn't do anything -- the CLI is unresponsive since that command is issued and I have to send commands via ssh and there are snapshots from the snapmirror that are still busy: Volume orabackup working... %/used %/total date name ---------- ---------- ------------ -------- 40% (40%) 28% (28%) Jan 29 15:34 flatcar(0101184681)_orabackup.3664 (busy) 40% ( 1%) 28% ( 0%) Jan 29 14:34 flatcar(0101184681)_orabackup.3663 (busy) Netapp support recommended rebooting the source, which seems a bit drastic (and hard to do midweek) esp. since there are two other snapmirror jobs working fine, and in other respects everything is well. The immediate problem is that those snapshots are eating a lot of space and I get: > snap delete -a -f orabackup snap delete -a: Remaining snapshots are currently in use by dump, snap restore, SnapMirror, a CIFS share, RAID mirroring, LUNs or retained by SnapLock. Please try to delete remaining snapshots later. if I try to delete them manually... This problem started when the destination filer suffered a power outage, presumably in the middle of a snapmirror transfer on the orabackup volume. any ideas short of a reboot? Thanks, Adi

3 4

Re: IBM SAN Volume Controller
by Alan McLachlan 06 Feb '08

06 Feb '08

Hi David, Of more interest - why? Your NetApp provides superior block virtualisation than the SVC, in nearly all respects - more flexibility, simpler management and better raw performance. Having BOTH an SVC and a NetApp layer in front of your raw disk array (DS series?) simply adds complexity and overhead. I can only assume that you currently have the NetApp purely for NAS and perhaps iSCSI? It sounds like you are planning to implement SVC in circumstances where your existing NetApp is not an appropriate model to take on the additional block virtualisation tasks, but if not how old is the SVC cluster? Have you considered simply replacing the SVC in your solution, and/or the older NetApp you have with an appropriately sized NetApp to provide an holistic storage management solution for all protocols (FCP/iSCSI/CIFS and/or NFS) with a single point of administration? regards, Alan McLachlan. ----- Original Message ----- From: "David McWilliams" To: "NetApp list" Subject: IBM SAN Volume Controller Date: Tue, 5 Feb 2008 11:40:13 -0500 I'm currently on 6.5.6. Does anyone know what version of ONTAP support the IBM SAN Volume Controller? -- Sláinte, David Get a safer, faster, better web browser @ http://www.mozilla.org/products/firefox/ -- Want an e-mail address like mine? Get a free e-mail account today at www.mail.com!

1 0

SnapDrive User Permission Lockdown
by Christopher Mende 05 Feb '08

05 Feb '08

Hi All, We've all been asked this question before -- does the snapdrive account HAVE to be a domain admin, and be an administrator on the filer? I've played with making the shares to the LUN-containing volumes read-only, but most of that is just a panacea. Here is an IIS server which is accessible to multiple outside entities. Specifically, looking to lessen the impact the snapdrive account may have on the filer, should the IIS server be compromised. I suspect the answer is "it doesn't matter" because you could wreak the same damage from Administrator if compromised -- but I just gotta ask. Thanks! Christopher

2 1

OnTap 7.2.x and NFSv4: krb5.keytab not created?
by Nathan Patwardhan 03 Feb '08

03 Feb '08

Hello, When I've setup new filers in our environment, I always enable Kerberos when I do an 'nfs setup' (as well as joining a Windows domain w/'cifs setup'). As a result of doing this, I noticed that /etc/krb5.keytab is created as part of the setup process. This allows us to enable sec=krb5 at our leisure and when we configure nfs.v4 options on the filer and stop/start 'nfs', "things just work". Cool. However, when an existing filer has already been setup, that is, the filer already had a 'cifs setup' and has NOT had Kerberos enabled for NFS, I've noticed that /etc/krb5.keytab is not changed when I enable Kerberos during an 'nfs setup'. No matter whether or not I stop/start 'nfs' after I'm done with 'nfs setup', I'm unable to use NFSv4 on the filer until I re-run the entire cifs AND nfs setup (a closer view of the messages file suggests that the filer can't find a service principal for 'nfs' in its keytab). It appears then that enabling NFSv4 on the filer is not an online event as I'd expect and that I have to terminate all of my cifs sessions so that I can run through the cifs setup again. Uggh. Can someone confirm if they've seen this behavior before? Or am I just missing something? Outside of running 'ktpass' on the Windows KDC and securely copying krb5.keytab from it to the filer, is there another way I can generate a new krb5.keytab or update the existing krb5.keytab on the filer? Or is there a utility I can use to see what lives in the krb5.keytab on the filer? 'klist -k -e ...' doesn't seem to like the format of it. -- Nate

1 0

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