toasters

toasters@lists.teaparty.net

13520 discussions

3170 NFS weirdness
by Randy Rue 01 Dec '11

01 Dec '11

Hello All, We run a VMWare farm that mounts its datastores via NFS on two different NetApp clusters, one a 3020 HA pair running 7.2.4 and the other a 3170 running 7.3.5P5. We also mount those datastore exports to two linux (CentOS 5.x) hosts, which have the CommVault/Simpana backup agents installed. We effectively back up a snapshot of those datastores. We've been testing restores of files back to the datastores on the 3170 and they've been failing. We get a linux Error 13, basically "permission denied," in spite of the fact that the exports are configured for root access to both the ESX hosts and the backup hosts. We've confirmed that the backup hosts are mounting as root. This works on the 3020 pair. Can't spot any meaningful differences in "options NFS" between the two NetApp systems, or in any other setting. Thought it might be a posix permissions issue as a CV restore runs under the local linux group "simpana." The files are written with ownership of root:simpana and then permissions are changed when the data is all there. But if we try to rsync any test data to the 3170 datastores we get the same error, even if we're logged in as root and copying from a local directory on the backup host. Weirder, we CAN write to the datastore folder using cp, rm, mkdir, rmdir, but NOT using rsync. Help?

4 3

8.1 32->64bit volume convert
by Fletcher Cocquyt 30 Nov '11

30 Nov '11

Hi, We're testing out Ontap 8.1RC2 Can someone point out/describe the procedure for converting volumes from 32bit to 64bit? thanks Fletcher

11 23

moving vol0 from one aggregate to another with zero downtime using failover?
by Cotton, Randall 28 Nov '11

28 Nov '11

On an N3400 active/active w/DOT 7.3.5.1P1: I need to move vol0 from aggr0 to aggr1 on node A (so I can nuke its aggr0). I've done this kind of thing on a single independent node - it's fairly well-documented in the "Storage Management Guide". Basically: 1. Create a newvol0 on the destination aggregate of adequate size 2. ndmpcopy /vol/vol0/etc over to newvol0 3. vol options newvol0 root 4. reboot But in this situation, there's stuff on aggr1 I'd like to keep serving during this transition. I'd like it very much if I could use failover to do that. Is it possible to pull this off with a takeover/giveback? It seems it might be problematic what with the takeover node presumably using /vol/vol0 as the root vol and the other node booting up using /vol/newvol0 as the root vol. Would the giveback work OK? It seems there's room here to really hose things up. Any advice? Anyone seen documentation on such a procedure? R

5 4

tracking pBLKs
by Jon Hill 28 Nov '11

28 Nov '11

Is there any way to monitor and alert on pblock utilization via DFM or another monitoring tool? We had an issue recently where CIFS operations ground to a halt that was not resolved until we disabled fpolicy. We believe the entire pblock pool wound up in use and CIFS operations ground to a halt. We're considering running something like this to ensure that CIFS never runs out of pBLKs in the future: setflag fp_maxcifsreqs_pblkpercent X But we want to determine what the current range is before we make any changes. Cifs stat shows the value under Max pBLKs = xxx, but XXX is a number without context, like 1700, and doesn't help much. This e-mail, including any attachment(s), is intended solely for use by the named addressee(s). If you are not the intended recipient, you are not authorized to disclose, copy, distribute or retain this message, without written authorization from Jennison Associates LLC ("Jennison"). This e-mail may contain proprietary, confidential or privileged information. If you have received this message in error, please notify the sender immediately. If you have requested Jennison to e-mail any account information to you or your designee, you are deemed to have consented to electronic delivery of information from Jennison. E-mail messages are not secure and may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient.

2 1

Cifs user name mapping.
by Jeff Cleverley 22 Nov '11

22 Nov '11

Greetings, We have a cifs share that gets worked on by various people in the company in different countries and business groups. We have access opened up to users with a valid Windows 2003 Server domain authentication. Since we don't know everyone who will have access to this, we don't have unix accounts for them, or entries in the usermap.cfg file. This share is also nfs accessed and has unix security style. The problem is when we look in the messages files these users seem to show up with their workstation name followed by the $ sign. It's difficult to track who owns the machine and who logged into it. Here is an trimmed example entry: auth.trace.authenticateUser.loginAccepted:info]: AUTH: Login by dwc46q1$ from xx.xx.xx.xx accepted. I'd like a better way to figure out who logged in from dwc46q1$ . The cifs.trace_login is on. Thanks, Jeff -- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611

2 2

shelf id mismatch
by Chaim Rieger 19 Nov '11

19 Nov '11

I have a shelf that displays ID 4 however when i do show disk they come up as belonging to ID 0. This probably happened because the ID was changed, then powered off, then connected to the loop, then powered on. Just a guess... I am not comfortable with removing a full shelf from a loop (even though all these disks are marked as spares currently) Therefore my question is, if i remove one disk at a time, and reseat it. will it come up as ID 4, or ID 0 ?

3 6

mpha confusion
by Chaim Rieger 18 Nov '11

18 Nov '11

assuming i have two loops (id 00-04, and 10-18) 1 4 port sas card (0a-0d) loop 1 00A connects to 001a 0a 00B connects to 001b 0a ... 04A connects to 001b 0b 04B connects to 001a 0b loop2 10A connects to 001a 0c 10B connects to001b 0c ... 18A connects to 001b 0d 18B connects to 001a 0d KEY = 00A = Shelf ID 00 Module A 001A = Filer 001a/b 0a = SAS port A Its been a long three days of no sleep, but this is mpha, correct ?

6 8

How do I find the driver version for the FC HBA's on my 3170?
by Randy Rue 15 Nov '11

15 Nov '11

Upgrading the attached SAN and the vendor wants to know this...

3 2

Snapshot reserve
by Vincent Liggio 11 Nov '11

11 Nov '11

We tend to have very large file systems (largest NetApp one is > 40tb), and the default 20% snapshot reserve starts to be a huge waste of space. Is there any good reason not to just set it to 0%? The snapshotted files aren't limited by the reserve, so what's the real point of it? A lot of times we end up with reserves that are only a few % in use, so it's truly wasted space. I've been setting those ones to have small reserves, and the discussion ensued whether it's worth having any reserve at all. Thanks. Vince Blue Sky Studios

4 3

Clarify ndmpcopy behavior.
by Jeff Cleverley 04 Nov '11

04 Nov '11

Greetings, I was experimenting with ndmpcopy and got an unexpected result. I was wondering if anyone can clarify if this is correct behavior or not. I've tried it on both 7.3.3P5 and 8.1RC1. I got slightly different error messages, but both failed. I set up a source directory of foo and populated it with some data. I ran the following command which worked: ndmpcopy /vol/perf_test/foo /vol/perf_test/foo2 The part that broke was I deleted the zoneinfo directory from foo2, then ran the same command with the "-l 1" option. I got the following error: Ndmpcopy: easystreet: Log: RESTORE: Invalid operation: ./zoneinfo I was expecting it to put zoneinfo back into the destination. I started over again and used the "-d" option for the level 1 incremental. The log file had no additional information. Should an incremental put this directory back? Thanks, Jeff -- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611

2 2

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