toasters

toasters@lists.teaparty.net

13531 discussions

scsi.cmd.abortedByHost:err
by Stuart Kendrick 23 Feb '12

23 Feb '12

Is this telling me that the HBA in the filer ('toaster-a') aborted the SCSI command? Or that the port on the back-end storage (a 3Par T800) aborted the command? Mon Jan 30 22:27:45 GMT [toaster-a: isp2400_intrd: *scsi.cmd.abortedByHost:err*]: Disk device 0a.0L2: Command aborted by host adapter: HA status 0x4: cdb 0x28:4d4dfc37:0009 --sk

1 1

RE: upgrade a FAS980 with 10GB network cards possible?
by Bill Holland 22 Feb '12

22 Feb '12

The FAS30xx series do. It is a single port card. Sent from my Galaxy Nexus Kenneth Heal <kheal(a)hotmail.com> wrote: > >Hi > >True, but there isn't a PCI-X 10gbE adapter supported in any model or version of ONTAP so I would doubt that ONTAP has a driver for it or that it would work. > >If anyone can prove me wrong I'd be keen to hear it. > >Sorry for not being more explicit. > >regards >Kenneth > >---------------------------------------- >> Subject: Re: upgrade a FAS980 with 10GB network cards possible? >> To: kheal(a)hotmail.com; toasters-bounces(a)teaparty.net; bormann(a)bbtel.de; toasters(a)teaparty.net >> From: jack1729(a)gmail.com >> Date: Tue, 21 Feb 2012 14:21:19 +0000 >> >> If he is using a FAS980 - I doubt he is worried about it being supported >> Sent from my Verizon Wireless BlackBerry >> >> -----Original Message----- >> From: Kenneth Heal <kheal(a)hotmail.com> >> Sender: toasters-bounces(a)teaparty.net >> Date: Tue, 21 Feb 2012 14:55:51 >> To: RenÃ© Bormann<bormann(a)bbtel.de>; <toasters(a)teaparty.net> >> Subject: RE: upgrade a FAS980 with 10GB network cards possible? >> >> >> Hello René >> >> I do not believe this is possible. Looking at the system configuration guides I don't see any supported 10gbE cards even for the FAS-3020 which also uses PCI-X slots. >> >> I believe the minimum hardware for 10 gbE would be a FAS-3040, which uses PCI-e. >> >> Servus, >> Kenneth >> >> ---------------------------------------- >> > Date: Tue, 21 Feb 2012 14:28:01 +0100 >> > From: bormann(a)bbtel.de >> > To: toasters(a)teaparty.net >> > Subject: upgrade a FAS980 with 10GB network cards possible? >> > >> > Hello Toasters, >> > >> > is it possible to use a 10GB network card in a FAS980 ? >> > >> > Cheers, >> > >> > René >> > >> > >> > _______________________________________________ >> > Toasters mailing list >> > Toasters(a)teaparty.net >> > http://www.teaparty.net/mailman/listinfo/toasters >> >> _______________________________________________ >> Toasters mailing list >> Toasters(a)teaparty.net >> http://www.teaparty.net/mailman/listinfo/toasters > >_______________________________________________ >Toasters mailing list >Toasters(a)teaparty.net >http://www.teaparty.net/mailman/listinfo/toasters

4 3

stuck creating an aggregate?
by Randy Rue 21 Feb '12

21 Feb '12

Provisioning a half dozen new aggregates on a new 3240 and while most of them completed within seconds, two are stuck at "initializing." Can't offline them, destroy them, or do anything at all to them without getting an error about the operation not being permitted on an aggregate that's still being created. One of them has been in this state for an hour now. Any advice? Anything I can do to shake them loose? Or should I just go take a nap and hope for the best?

3 2

upgrade a FAS980 with 10GB network cards possible?
by René Bormann 21 Feb '12

21 Feb '12

Hello Toasters, is it possible to use a 10GB network card in a FAS980 ? Cheers, René

4 4

vFiler migration with flex-clones fails - Volume is a clone and scanners have not completed on the parent volume: cannot execute operation
by Fletcher Cocquyt 20 Feb '12

20 Feb '12

It takes almost 6 hours to run the initial snap mirror sync for this vFiler migration, and its failed twice with Waiting for SnapMirror-Resync to complete on 'dbdev2, dbdev5, dbdev7' flex-clones… then SnapMirror Resync failed: Reason: SnapMirror error: Volume is a clone and scanners have not completed on the parent volume: cannot execute operation Src and dest are 3270 clusters running 8.1RC2 This is the last remaining migration blocking our long awaited shelf upgrade - and we have a case open with Netapp Anyone seen this one and worked around it? Thanks, Fletcher

2 4

FAS2240 and SSD
by Milazzo Giacomo 20 Feb '12

20 Feb '12

Hi all, expected for january 2012 there was the support to partially loaded DS4243 with 100 GB SSD units: 6 or 12. This was also reported in the "FAS2240 Technical questions" document by Chris Lueth. I'm trying to find some official doc that reports now this. Are these units really already supported on FAS2240? Regards Dott. Giacomo Milazzo [Descrizione: cid:image001.jpg@01C75422.0D316270] Technical Account Manager Sinergy SpA Filiale di Roma * 00198. viale Regina Margherita, 269 ' (+39) 3406001045 0644245272 7 (+39) 0226922048 * Giacomo.Milazzo(a)Sinergy.it

6 7

Storage VLAN ID assignment strategies?
by Ray Van Dolson 18 Feb '12

18 Feb '12

We have a range of VLAN IDs dedicated to storage related networks. Any of you out there find any value in reserving certain ranges for certain types of storage traffic (e.g. iSCSI, FCoE, NAS, etc all in different ranges)? Simplest is to just start at the lowest value and assign to the larger numbers, but maybe I'm missing some benefit for staying more organized here. Ray

2 1

deduplication, snapshots and performance questions
by Randy Rue 16 Feb '12

16 Feb '12

Hello All, We're troubleshooting some performance issues and trying to determine how deduplication might be might be muddying the waters on an already busy v3170 HA filer pair. There's also some likelihood that snapshots are involved. In a nutshell we have two Vfilers running on one node. One serves NFS datastores to our VMWare farm and all its volumes are de-duped. We recently migrated the other to the node, it's serving NFS to a wide variety of hosts and IO tends to be very heavy on metadata (get_attr and set_attr). We've found a pretty clear correlation between running de-dupes and performance complaints from customers of the other Vfiler. Whether we're running one de-dupe session or eight, CPU3 stays in the mid-high nineties. This is consistent with what NetApp has told us: that de-dupe processes live in the "Kahuna" domain that always ends up on one proc (in our case, the last of the four). They've also told us that de-dupe processes are heavily "niced" and shouldn't impact other processes, but after just having finished reading their 75 page PDF TR-3505 ("NetApp Deduplication for FAS and V-Series Deployment and Implementation Guide"), it's pretty clear the answer is a huge "it depends" and that de-dupe processes have a very real impact on performance. Especially if we're talking about a system that's otherwise heavily used, that is a higher model number, and that is using ATA drives (bingo on all three). Does anyone have any real-world experience with de-dupe processes impacting performance? Any suggestions for tuning? We've spent some time moving the schedules around but kept finding that efforts to spread them out were pretty fruitless: some volumes took much longer than others and eventually they started overlapping and stacking up. Right now we're running a script from another server that checks to see how many de-dupes are running and launches new ones as old ones complete, depending on what time it is. The end result is we run a constant loop over a list of fourteen VMWare datastore volumes with two de-dupes running on nights and weekends and none during the day. This means it takes about three days for that list to repeat; we used to run each volume every other day so we're watching the size numbers to make sure we don't hit any walls on the aggregates. Here's a tangent question. Does anyone know if, everything else being equal, two equal de-dupe jobs will complete faster if they're run sequentially or in parallel? If this process really is confined to a single proc and the work to be done is directly related to the ops available the blocks to be changed, it seems like should be a wash, but we haven't collected enough data to figure this out for ourselves (I'm afraid if we spend too much time running at only one process we'll have space problems). To add snapshots to the mix: we're running hourly snapshots on most or all of the volumes on both Vfilers. NetApp has told us this adds considerable performance load, most notably the work involved in releasing a snapshot as the oldest one rolls off the stack. They've said they can see instances in the logs where a snapshot begins before the previous one is finished. We're considering splitting the volumes into two groups and snapping them at alternate hours, so we get protection at two-hour granularity but each hour we're only processing half the volumes. However. Won't we then be processing twice as many changed blocks for each snapshot? Do we gain anything? We had this exact problem, for example, with a different storage vendor with a similar snapshot implementation. In that case their solution was actually to step up to snapshots every half hour. It ended up that processing smaller hunks of changed blocks more often solved our problem. Right now we're leaning toward trying a hybrid of these two approaches on our NetApp, splitting the volumes into two groups and running them at the top and bottom of the hour. We still get hourly snapshots on all volumes but only need to parse half as many in each pass. Anyway, I've rambled a lot and asked not many specific questions. What I'm hoping to hear is about: * Whether de-dupe processes scale linearly (do two jobs in parallel take the same total time as sequentially) * Anyone's experience tuning de-dupe processes and/or snapshots to minimize performance impact. Hope to hear from you, Randy

5 4

QFULL / vFiler
by Stuart Kendrick 15 Feb '12

15 Feb '12

How do I look for QFULLs on a vFiler? FAS3020 lun-stats -o -a /vol/vmware/vmware_db.lun (67 days, 5 hours, 14 minutes, 4 seconds) Read (kbytes) Write (kbytes) Read Ops Write Ops Other Ops QFulls Partner Ops Partner KBytes 0 0 0 0 0 0 0 0 V3170 lun-stats -o -a [empty output] --sk

1 0

Flash Cache questions: symmetrical cache mode required? Metadata mode only with a 512GB Flash Cache?
by Robert McDermott 11 Feb '12

11 Feb '12

Hello, We a V3170 cluster with a 512GB Flash Cache module installed in each controller. Each module is currently configured to cache normal data (default setting): flexscale.enable on flexscale.lopri_blocks off flexscale.normal_data_blocks on We have a vfiler running on one controller that does very little normal IO but has a very heavy metadata load due to poor application design. This vfiler has poor performance and its function is critical. We are thinking about switching to metadata only caching mode (flexscale.lopri_blocks off, flexscale.normal_data_blocks off) to improve its performance but have a couple of questions: The Flash Cache best practices guide has the following verbage about enabling metadata only mode: "Because of the much larger size of Flash Cache, this mode is more applicable to PAM I, the original 16GB DRAM–based Performance Acceleration Module, than Flash Cache." Does that mean that this setting doesn't apply (not recommended/supported) for Flash Cache? but is for PAM I? Is using metadata only mode a bad idea with a large flash cache module? If so why? The best practices guide also indicates that it's recommended to have a symmetrical number and size of modules between controllers in a cluster, but it doesn't say anything about symmetrical cache mode settings. Is it OK to have one controller's flash cache set to the normal data setting, but the others flash cache set to metadata only? During a failover the cache of the failed controller is essentially lost (doesn't follow it to the remaining controller) so it doesn't seem like it would matter as long as the cluster didn't stay in this failover state for a long period of time. What are your thoughts on this? Thanks in advance, -Robert

9 8

tracking aggr initialization progress ?
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

Is there a way to track the progress (% complete?) for aggr creation/initialization? aggr status Aggr State Status Options aggr1 creating raid_dp, aggr raidsize=20, initializing snapshot_autodelete=off, 32-bit lost_write_protect=off thanks Fletcher

4 3

Re: The following prevents offline of volume: zapi snapshot list
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

The snapshot process must have completed - I was able to offline by waiting a few minutes thanks Fletcher On Feb 10, 2012, at 2:31 PM, Parisi, Justin wrote: > Are you able to reboot the box? Because those will need to complete otherwise before it allows a vol offline. > > If you try to force the vol offline, it will hang. Reboot will clear this up and you should be able to offline the vols. > > From: toasters-bounces(a)teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt > Sent: Friday, February 10, 2012 4:57 PM > To: toasters(a)teaparty.net > Subject: The following prevents offline of volume: zapi snapshot list > > Hi > I'm attempting to offline all the volumes on this 64bit aggr so I can destroy and re-create as 32 bit (so 32->32 bit data motion is supported) > > I am encountering this error: > > The following prevents offline of volume vm2 > zapi snapshot list > zapi snapshot list > zapi snapshot list > > How do I clear it so I can proceed? > > thanks > > Fletcher > > > > > >

1 0

The following prevents offline of volume: zapi snapshot list
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

Hi I'm attempting to offline all the volumes on this 64bit aggr so I can destroy and re-create as 32 bit (so 32->32 bit data motion is supported) I am encountering this error: The following prevents offline of volume vm2 zapi snapshot list zapi snapshot list zapi snapshot list How do I clear it so I can proceed? thanks Fletcher

1 0

dedup changed in 8.1?
by Fletcher Cocquyt 10 Feb '12

10 Feb '12

Last night (first since the upgrade from 7.3.5.1P2 to 8.1RC2) we experienced much higher load on our 3270 cluster and some VM timeouts coinciding with our dedup schedule (11pm -2am) Anyone heard if dedup changed in 8.1? I am disabling the regular dedup schedule until this is sorted out thanks Fletcher

5 5

nfsstats help
by Jeremy Page 09 Feb '12

09 Feb '12

How do I find out what's causing these messages and what the severity is? With large chunks taken out: Server rpc: TCP: calls badcalls nullrecv badlen xdrcall 72337 4294847830 0 0 4294847830 No of RAID errors propagated by WAFL = 2184604 It certainly looks bad but I am not sure if this is a big deal or not. I've been seeing some ugly latencies on my NFS traffic over the past day or so and I'm trying to determine what it could be. They are running in the 15-20 ms range (from stats show -i5 nfsv3) where normally it's under 5ms. Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 0

Force 64bit aggr migration
by Fletcher Cocquyt 09 Feb '12

09 Feb '12

Anyone know if its possible to force the in place 32->64bit aggr non-disruptive migration without having to add disk? I'm running into a 8.1R2 data motion issue where NMC is refusing to migrate vFilers from the 32 bit source cluster to the 64bit destination. The destination aggrs are at or above 16Tb so they need to be 64 bit thanks Fletcher

4 4

Fas 3240 failover delay
by John Sfetsoris 09 Feb '12

09 Feb '12

Hello everybody I have a Fas3204 HA in two seperate chassis , dataontap version 8.02P3 7mode. Many NFS servers are connected to it via iscsi connections. NFS servers are VMware mashines . VMware version is VSPERE 5. There are 4-5 Vfilers running. When i force a failover from the one controler to other, the NFS clients have a delay about 30-40 seconds. Is this normal? Can i do something to investigate/tune the failover proccess? thnks in advance John

5 6

Re: NDU from 7.3.5.1P3 to 8.1RC2 supported?
by Fletcher Cocquyt 09 Feb '12

09 Feb '12

I found and corrected the typo in the rc file - now the check passes on the rc files, but not the running config. Is it safe/recommended to reissue the ifconfig na03-vif0-205 `hostname`-na03-vif0-205 netmask 255.255.255.192 partner na04-vif0-205 up to update the partner in the running config? Or is there a better method? thanks -- Fletcher On Jan 31, 2012, at 2:48 PM, Chris Muellner wrote: > Verify the RC files on both controllers. You can ignore the c0x interfaces, but the tool is saying you’ll have an issue with this VIF here: NO PARTNER FOR na04-vif0-205 (17.25.104.23) ON na04 in /etc/rc > > Make sure the ifconfig statement in both controllers RC files for that interface have the partner interface specified in the statement. > > From: toasters-bounces(a)teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Fletcher Cocquyt > Sent: Tuesday, January 31, 2012 1:01 PM > To: SW > Cc: toasters(a)teaparty.net > Subject: Re: NDU from 7.3.5.1P3 to 8.1RC2 supported? > > Thanks for the feedback Steve, > > I'm also running the netapp tool to check HA prior to failover: > Are these partner network errors valid? Someone in the community forums said they are bogus > > ./ha-config-check.cgi -s na03 na04 > == NetApp HA Configuration Checker v2.0.0 == > > > Checking ssh logins ... > > > Checking ssh logins ... > > OK > > Checking Data ONTAP versions... > > OK > > Checking licenses... > > OK > > Checking HA configuration identity... > > OK > > Checking cf status... > > OK > > Checking fcp cfmode settings... > > fcp: FCP is not licensed. > N/A > > Checking options... > > OK > > Checking network configuration... > > c0a (192.168.1.152) on na03 does not have a partner on na04 > c0b (192.168.2.173) on na03 does not have a partner on na04 > c0a (192.168.1.84) on na04 does not have a partner on na03 > c0b (192.168.2.95) on na04 does not have a partner on na03 > na04-vif0-205 (17.25.104.11) on na04 does not have a partner on na03 > > > > > Checking network config in /etc/rc > > NO PARTNER FOR na04-vif0-205 (17.25.104.23) ON na04 in /etc/rc > HA configuration issue(s) found above. Please correct them and rerun this script. > Done. > > -- > Fletcher > > > > > On Jan 31, 2012, at 10:29 AM, SW wrote: > > > Hi Fletcher, > > I only have a subset of answers relating to your Toasters inquiry, but I thought I’d share what I can... > > According to the upgrade guide for 8.1RC2 (attached to this e-mail), a NDU from 7.3.5.1P3 to 8.1RC2 is supported: > > > From page 15: > “Nondisruptive upgrades to releases in the Data ONTAP 8.1 7-Mode release family are supported > from the following releases: > • Any 8.0.x release > • 7.3.2 and later 7.3.x releases” > > Good luck! > Steve > <upgrade.pdf>

6 10

vfiler migrate: overview and thoughts
by Randy Rue 09 Feb '12

09 Feb '12

vfiler migrate: overview and thoughts When I first read there was a way to move a vFiler from one node of a NetApp cluster to another I was excited. I was imagining something akin to VMWare's vMotion, a transparent movement of services. Digging a little deeper showed that NetApp's "vfiler migrate" functionality isn't nearly as automagic as I'd hoped. Here are some observations. * Disk ownership of the resources must be software based whether your filer is using actual disks or array LUNs (on a vSeries filer like our 3170). We had some concerns that the feature might not work well with array LUNs but it appears that Data OnTap doesn't know any difference between an Array LUN and an actual disk in this context. * The vfiler migrate command effectively moves complete aggregates from one filer head to another. This means that all volumes on the aggregate(s) involved must be tied only to the vfiler being moved, with no LUNs, exports or shares presented from the context of the root filer or any other vFiler (in our environment we already had a standard of creating separate aggregates for each vFiler so this wasn't a problem). For example, after one failed attempt to migrate a filer, I had added a CIFS share to the root volume of the vFiler via the root filer, to gain access to the etc folder of the vFiler. I forgot to remove that share, and broke later migration attempts for a new reason. * We've tested the vfiler migrate command dozens of times now on three different vFilers, in preparation for the migration of a production vFiler later this week. Two of those vFilers have migrated flawlessly every time, and one seems to fail about 30% of the time for various reasons which we can sometimes identify and sometimes not. * Reasons for failure include: - A CIFS share from the root filer head to the vFiler's root volume. My bad. - Possible FC noise between the root filer and the SAN behind it. - Possible SCSI reservations issues between the root filer and the SAN. - Invalid credentials (fat-fingered a password, I think) for the "source" remote root filer. Oddly, the migrate command still stopped the vFiler, offlined its volumes and aggregates, and removed the vFiler from the source root filer before the process failed. - Poor alignment of the planets? Bad karma? * In general, it seems that the vfiler migrate just fails sometimes. In every failure, however, recovery has been straightforward. The "vfiler create <vFiler name> -r <path to vFiler root volume>" command recovers the vFiler every time, albeit without a proper network configuration. The vFiler comes back up but with its virtual NIC having no subnet mask or assignment to a physical interface. Makes sense, I guess, as the migrate command never got to the part where it normally asks what mask and interface to use. This needs to be reassigned, either from the CLI using ifconfig or the "manage vFiler" wizard in FilerView (note that this will also overwrite etc/exports with a default but will save a backup first). Given that there are arguably a slew more shops out there running HA VMWare clusters than there are running HA NetApp clusters, it's probably not fair to expect that vfiler migrate is going to be as slick or even as well understood/documented in the wild as vMotion. Also, inherent limitations in things like the CIFS protocol make it necessary that some services will have to be interrupted. But overall I'd claim that the feature is useful and even when it doesn't work as hoped recovery is straightforward and reliable. We're planning on proceeding with our production move later this week. Hope this helps anyone in the same situation, Randy

4 5

nfsiostat and client NFS connections
by Randy Rue 08 Feb '12

08 Feb '12

Hello All, Trying to troubleshoot performance problems on our v3170. This is not specifically a NetApp question but if nothing else, the tool I'm using appears to have been written by a NetApp engineer, does that count? Running nfsiostat on a handful of impacted clients on another network and uploading the results to a timestamped log file served on a web server so I can reach them. I have a script that parses those pages, takes the last timestamped entry from each file (one file for each client), and tallies up a) the average RTT time for all mounts to the vFiler and b) the worst single instance. Now that I have it all working, the numbers don't believe like I think they should. The clients are adding an entry to each file every minute. I can see that from the timestamps before each entry. But the numbers don't change. Or they change by a few hundredths of a ms. My gather script returns an average that varies only by .01ms or so, and my "worst" figure has been steady for an hour now. We're running nfsiostat with no arguments. Am I getting real time readings or some average? If average, since when? Is there a way to get real-time? Hope to hear from you, Randy Rue

9 16

Re: FlexShare
by Jack Lyons 08 Feb '12

08 Feb '12

I had an SE say the same thing and stayed away from it also for same reason - we have an older filer that gets pounded in evenings and was wondering if anyone had a big success story. Thanks Jack ------Original Message------ From: Scott Eno To: Jack Lyons Cc: toasters(a)teaparty.net Subject: Re: FlexShare Sent: Feb 8, 2012 9:06 AM Hi Jack, I have done some small testing with it, but I shied away from implementing it when a NetApp instructor said that to get the best results you have to apply it to ALL the volumes on the filer hosting the particular volume(s) you are looking to improve performance on. Not sure if that's true or not, but it was his suggestion. I figured if that were the case I would be spending a lot of time tweaking all volumes on a filer just to possibly squeeze a bit more out of one or two. --- Scott Eno (First time poster, long time reader) On Feb 8, 2012, at 7:20 AM, Jack Lyons <jack1729(a)gmail.com> wrote: > Has anyone used FlexShare and had extremely positive results. IT seems > that the improvement would be minor and misconfiguration could lead to > no improvement for intended volumes and degradation for others. From > reading, it seems that you need to assign priorities to each volume > otherwise the volumes in the default queue will experience degradation. > > Would anyone like to share details of how the implemented flexshare and > the impact it had on the performance issue they were working to resolve? > > Would also like to know if anyone has try to 'schedule flexshare' > settings using rsh or api e.g. we want to give higher priorities to > certain volumes from 6pm to 11pm nightly. > > Thanks > Jack > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > http://www.teaparty.net/mailman/listinfo/toasters Sent from my Verizon Wireless BlackBerry

2 1

vfiler migrate
by Randy Rue 08 Feb '12

08 Feb '12

A co-worker of mine already posted on this but we're coming up with more questions. We successfully tested the migration of a test vFiler from one node to the other and back. Took 3-4 minutes each way for a vFiler with one aggregate and two "disks" (it's actually got a 3Par SAN on the back end). Then we tried a vFiler with two aggregates of 14 and 15 "disks." It went from A to B with no trouble, took closer to six minutes. When moving it back from B to A it blew up. Got the following at the CLI: tungsten-a> vfiler migrate -m nocopy fhdata@tungsten-b tungsten-b's Administrative login: root tungsten-b's Administrative password: Stopping remote vfiler.... vfiler migrate: Aggregate 'fhdata_aggr1' has failed and cannot be brought online. Problem bringing aggr fhdata_aggr1 online: CR_VOL_FAILED vfiler migrate: No aggregate named 'fhdata_aggr2' exists. Couldn't find aggr fhdata_aggr2 in order to bring it online vfiler migrate: No volume named 'fhdata_root' exists. Couldn't find flex-volume fhdata_root in order to bring it online vfiler migrate: No volume named 'fhdata_shared' exists. Couldn't find flex-volume fhdata_shared in order to bring it online vfiler migrate: No volume named 'fhdata_viddshared' exists. Couldn't find flex-volume fhdata_viddshared in order to bring it online Problem bringing vfiler fhdata volumes online. tungsten-a> tungsten-a> vfiler status -r fhdata Vfiler not found: fhdata tungsten-a> At first there was no sign of the vFiler, aggregates or volumes on either A or B. After a few minutes, part of one aggregate was visible on A. A few minutes after that we could see both aggregates and all disks. Brought the aggregates online and the all the volumes. The vFiler is still gone, no sign of it on either node. Does the vfiler migrate command support vFilers with more than one aggregate? Note that all the volumes for the vFiler live on two aggregates and no other volumes are on those aggregates. While we're on the subject, does anyone know where the configs for a vFiler actually live? Right now my hope is to rebuild the vFiler and reattach the volumes but I'm hoping to at least be able to see what CIFS shares it had, for example. We save a nightly tarball of the complete contents of etc$ so if it's in a config file somewhere I can find it. On the phone with NetApp support right now but I'm hoping someone has experience with this in the real world. Hope to hear from you. Randy

2 2

Filer behavior differences between 7.3.3 and 7.3.5.
by Jeff Cleverley 07 Feb '12

07 Feb '12

Greetings, Has anyone upgraded from any version of 7.3.3 to a 7.3.5 variant seen any behavioral differences? I also upgraded diagnostics from 5.5 to 5.6.1. I upgraded 2 clusters from 7.3.3P5 to 7.3.5.1P4 at the first of the year. One cluster is a 6040 and the other is a 6080. Both have similar layouts of disk space and usage, CIFS, NFS, PAMII cards, 10G networking, etc. After the upgrade, the 6040 cluster is behaving normally. Our NMS monitoring server immediately started reporting SNMP polling timeouts for the 6080 cluster. There were over 130 errors for each head within the first 2 days and 0 for the entire month of December. The 6080 cluster has user home directories via NFS. I see periodic "hiccups" in response on my workstation, as have other users. We had one of the filers panic due to a failed SAS controller a couple of weeks after the upgrade. During that failover time, there were a lot more complaints about unacceptable performance until I got the replacement part and failed things back. I was able to pull a performance graph from the first of December to the end of January for both filers. This data came from SNMP queries of the filers. You can clearly see that the baseline CPU utilization was ~40% before the upgrade and ~60% after the upgrade. That would also account for the poor performance during the cluster failover since one filer head can't maintain the load (60%) for both heads without degrading performance. Through all of this, nothing changed but the OS and diagnostics firmware. I just reinstalled the OS again this weekend just to make sure everything was happy with it. There has been no change. I've got a call open with NetApp but they are not seeing anything wrong and are unable to explain what is driving the CPU higher since everything looks acceptable to them. Unfortunately I did not do a perfstat collection prior to the upgrade so there isn't anything to compare it to. I did find the option nfs.mountd.trace option became very verbose after the upgrade (prior post on that) and had to be turned off. I'm wondering if there are any other issues anyone else may have found after this type of upgrade? Thanks, Jeff -- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611

2 1

anybody has experience using snapmover?
by Kawakubo, Ken 06 Feb '12

06 Feb '12

Dear list, We have an active-active cluster with vfilers. One vfiler in node-1 is having performance issues. Since node-1's CPU usage is much higher than node-2. I would like to migrate the vfiler from node-1 to node-2. I found a feature called snapmover in vfiler manual. I found that the command "vfiler migrate -m nocopy" migrates a vfiler from node-1 to node-2 without actually copying data. This command merely changes the software disk ownership of disks that make up the vfiler and is non-disruptive. Furthermore, snapmover is now a non-license feature. Sounds too good to be true? I want to know if there is any gotcha using snapmover. Does anybody have experiences using "vfiler migrate -m nocopy" command? Our cluster is NetApp V3170. Regards, Ken Kawakubo

2 3

Volume Naming Conventions?
by Ray Van Dolson 04 Feb '12

04 Feb '12

Hello; Curious what type of volume naming conventions you all have found work best? We're about to expand our environment, and looking for ideas on ways to keep names somewhat formulaic and consistent across filers. Thanks, Ray

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