toasters

toasters@lists.teaparty.net

13520 discussions

Start a nNew thread

re[4]: Physical reallocate for a deduped volume
by Mathew Kilham 21 Mar '12

21 Mar '12

1 0

Query Netapp for NFS client mount options?
by Fletcher Cocquyt 21 Mar '12

21 Mar '12

I'd like to know which NFS clients are mounted with the noac option. Can I query OnTap 8.1RC2 for this info? If so, how? thanks, Fletcher.

2 1

Physical reallocate for a deduped volume
by Mathew Kilham 20 Mar '12

20 Mar '12

Hi Toasters, I've posed the following question to NetApp support but wasn't too confident in the answer I received, so I was hoping the knowledgeable folks on this list could assist? Also, before I begin, please excuse any ignorance or NetApp faux pas on my behalf, I'm far from an expert at administering NetApp filers. --- We have a FAS2050C running DOT 7.3.4. We recently added an external disk shelf to the filer and performed a bit of reorganisation, which has left us with two unused disks in the internal shelf. We want to add these two disks to an existing 16-disk aggregate by expanding it's RAID group size from 16 to 18. The aggregate is currently ~80% full and contains 5 flexvols, most of which have de-dupe and snapshots enabled. I understand that after expanding the RG / aggregate we need to run a physical reallocate or else we will end up with a significant "hot spot" on the newly-added disks. I also understand that we need ensure DOT only does a physical redistribution of the blocks across all disks in the aggregate and does not try to otherwise rearrange them, otherwise we risk "un-deduping" our deduplicated data and/or greatly increasing the space consumed by our snapshots. First question: I believe the command we need to run to perform the above style of reallocation is "reallocate start -f -p /vol/<volname>" - is that correct? I noted, however, that there is a warning with regards to the "reallocate -p" command in the release notes of 7.3.x. Unfortunately I can't find a link anymore, but it reads: "A file reallocation scan using reallocate start or reallocate start -p does not rearrange blocks that are shared between files by deduplication on deduplicated volumes. Since a file reallocation scan does not predictably improve read performance when used on deduplicated volumes, performing file reallocation on deduplicated volumes is not recommended. Instead, for files to benefit from the reallocation scan, they should be stored on volumes that are not enabled for deduplication." I then queried with NetApp how we could perform a physical reallocate on the aggregate to avoid a hot spot, given the above statement that "reallocate start -p does not rearrange blocks that are shared between files by deduplication on deduplicated volumes", and almost all of our data is deduped. After a bit of to-ing and fro-ing with NetApp, the final suggestion was as follows: "Ive talked to two senior resources so far about this. The suggested steps are as follows>> #1: add your disks to the aggregate, and then grow the volume. #2: Turn off Deduplication, ( no, this will not revert to the 2.5 gigs from the one gig ratio it is now and suddenly cause you to be out of space) this will only stop deduplication from this point forward until it is re-enabled later. Everything that is currently deduped will stay the ratio it is. #3: Perform the reallocate p command as specified in the KBs sent earlier. #4: After all above steps are performed and reallocate is done, re-enable deduplication on said volumes." Second question: Does this sound kosher - will this actually result in a physical reallocate being performed, or will the deduped blocks still be skipped because they're already de-duplicated, regardless of whether dedupe is enabled for new data on the volume or not? Third question: If yes to the previous question, is there any risk that our deduped data get un-deduped by performing the suggested steps above? Fourth and final question: Is there any way to measure how data is spread across disks in a Raid Group / aggregate, so that I can check that we get our expected results from the reallocate? Thanks everyone, really appreciate any feedback / assistance. Cheers, Matt

3 4

Strange error when running autosupport.doit
by Dan Finn 16 Mar '12

16 Mar '12

I noticed that when I run an autosupport.doit I get the following error: Thu Mar 15 15:39:16 MDT [na04: asup.general.file.create.failed:error]: AutoSupport file (/mroot/etc/log/.cm_stats_hourly_done) was unable to be written to the file spool subdirectory. But the autosupport email still makes it out and looks good. I deleted everything under /etc/log/autosupport and I also tested that I could create the file that is mentioned in the error manually as root, no issues there. Anyone else ever seen this before?

5 10

vfiler root IO and performance across aggregates?
by Randy Rue 15 Mar '12

15 Mar '12

Hello All, We're about to spin up a new 3240 active/passive HA pair with a few hundred SATA disks divided into five aggregates for best RAID distribution and overall IOps. We'll be serving up NFS data from a dozen or two volumes, divided across the aggregates for roughly even capacity and IO load. For clarity of management and to ease any possible portability issues later I like the idea of running all of this under a vfiler. Got a few questions first, however. Do I create any CPU/RAM bottleneck by putting all of this under one vfiler? For example, would I be forcing otherwise multi-threaded processes onto one CPU? (Oh, we're running 8.0.2P5 in 7-mode, BTW) I have to put the root volume for that vfiler on one of those aggregates. Will heavy processing traffic cause heavier disk IO to the aggregate housing the root? Or is the vfiler root held in RAM? Seems like it could be and would be a good idea to do it that way. In either case, seems like it would make sense to put the vfiler root on aggr0, which uses up three disks to create 1.25TB and otherwise only contains the physical filer's root. Any other considerations I should know about? Hope to hear from you, Randy

2 1

migrate a vfiler between different HA clusters?
by Randy Rue 13 Mar '12

13 Mar '12

Hello All, We have a vfiler "x" currently sitting on one node of a v3170 HA pair. We want to move it to a new 3240 HA pair. Looks like the automagic tools that NetApp offers for this can't work for us because a) the destination filer has less NVRAM than the source, and b) the source is at 7.3.5 and the destination 8.0.2. We could create a new vfiler on the destination and snapmirror every volume. But we don't use qtrees. There are default qtrees on the dozen or two volumes on the source vfiler, but these can't be snapmirrored to the destinations as (if I understand this correctly) directly as the snapmirror process first deletes the destination qtree and then recreates it. And if you delete the default qtree (qtree0) for a volume you delete the volume. In other words, this path would require we create a qtree below the default and end up with an added folder in the path of the copied destination folder, and need to touch every client that connects to the export. The new HA pair is in a different subnet than the source. So the IP address of the vfiler will change. But ideally nothing else should. Anybody got any ideas for how to do this short of creating a new vfiler from scratch and using rsync to move all the data via NFS? RE-assigning DNS names and AD memberships during a switchover outage?

2 9

DNS server failover timeout.
by Jeff Cleverley 12 Mar '12

12 Mar '12

Greetings, I can't find anything useful regarding DNS server entries in resolv.conf. The main filers in question are 7.3.5.1P4. We had the first DNS server in resolv.conf go down unexpectedly. The filers did not timeout the first server and go to the secondary in a timely manner. I was able to edit the resolv.conf files and rotate the order to get things happy again. This leads me to 2 questions: 1. Is there an option to set the DNS lookup timeout so that it goes to the next server in the list? 2. Does anyone know the default timeout before the filer goes to the next server in the list? Thanks, Jeff -- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611

1 0

Aggregate Committed Capacity in OpsMgr/DFM/Oncommand Console
by Fred Grieco 12 Mar '12

12 Mar '12

How is the "Aggregate Committed Space" calculated in DFM/OpsMgr, and can it be adjusted? The Aggregate Committed Space that I see in DFM is always seemingly too high, and this has been true in many version. When I add up the volume committed space in the volumes contained, add the aggregate reserve space, and divide by the total aggregate space, the percent is always lower than what DFM says by about 5%. Where do they get their number? Am I missing something? TIA, Fred

2 2

c-mode how to set NDMP blocking factor
by Mike Thompson 09 Mar '12

09 Mar '12

Hey all, I'm trying to increase performance of fiber channel NDMP backups we have going to a remote tape robot (bridged over WAN via some Cienna gear). I would like to try increasing the blocking factor that the filer uses when writing to tape over NDMP. I'm running Ontap 8.0.1 c-mode, with NetBackup 6.5. None of the docs explain how to do this, but there is mention of blocking factor in the Data Protection manual. All it says is that block size up to 256KB is supported, and that the variable MOVER_RECORD_SIZE is what controls that. It appears that you can send variable settings to NDMP by using 'set variable=value' at the top of your includes list in the backup policy in NetBackup. I have tried putting 'set MOVER_RECORD_SIZE=256' at the top of my includes list, and running the job, but I get this in the /mroot/etc/mlog/ndmpd.log: INFO: Pass through of unknown START BACKUP variable MOVER_RECORD_SIZE with value 256 I have also tried setting the variable DATA_BLOCK_SIZE, but get the same result. So the question is, how do I set the blocking factor for NDMP backups?

2 2

HbaPortToIomSquares_Alert
by Jon Bousselot 09 Mar '12

09 Mar '12

I've seen this message on two different filers now, a 2040 and a 3140 with multiple DS4243 shelves. It only shows up during a reboot, and I'm not finding anything on the NOW site. Both systems are running 8.1RC2. Any one else seeing this? -Jon Subject: HA Group Notification from filer01 (SAS Connectivity Monitor: HbaPortToIomSquares_Alert[2c]) WARNING

1 0

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