toasters

toasters@lists.teaparty.net

1 participants
13523 discussions

Start a nNew thread

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

from performance vs rg size to new topic: rg size uniformity within the aggregate
by Cotton, Randall 04 Nov '11

04 Nov '11

Unfortunately, I've not been enlightened as to performance numbers for varying small aggregate sizes with one raid group, so I guess I'll have to be content with shooting in the dark by starting out small and growing from there if the performance is too lousy. Regardless, may comments were still helpful and they are much appreciated. But now to a tangentially related subject: >From recent posts, one might be led to believe that it really doesn't matter much at all what the sizes of your raid groups are within an aggregate. One might get the idea that an aggregate with, say, 3 raid groups of size 6, 12 and 18 wouldn't perform much differently than one with 3 identical raid groups of size 12 because what matters far more than anything else is the data disk count of an aggregate: For instance: "...there is no reason one 4+2 and two 16+2s cant perform quite well. There is no unreasonable penalty to doing so ... if the right tools are used to manage it." "Performance of an aggregate is the total sum of spindles across the entire aggregate." And "Forget parity as a limitation to system performance" However, NetApp's recommendations on raid group sizing within the aggregate might lead one to believe somewhat the opposite: >From http://communities.netapp.com/thread/1587 : "the recommended sizing approach is to establish a RAID group size that ... achieves an even RAID group layout (all RAID groups contain the same number of drives). If multiple RAID group sizes achieve an even RAID group layout, NetApp recommends using the higher RAID group size value within the range." and "Drive deficiencies should be distributed across RAID groups so that no single RAID group is deficient more than a single drive." That is, NetApp took the time and trouble to say: 1. RAID group sizes within an aggregate shouldn't vary by more than 1 disk 2. Larger RAID group sizes are better (up to a point) Which runs rather strongly against the grain of what's been said recently in this forum. Can anyone shed more light on this topic? For instance, what are the drawbacks (and how bad are they) to, say, adding a 6-disk raid group to an aggregate consisting of one 16-disk raid group (instead of spilling for way more disk space than you might need by forking over for the full 16 disks necessary to even things out?). Thanks Randall

9 13

mixing disks in aggr
by Joosep Meus 04 Nov '11

04 Nov '11

Hi list! Currently we have 3 DS14mk4 shelves full of 300GB 3,5" 15K FC drives. All drives are in a single aggregate in three raid groups with two spare disks. Time has come to upgrade capacity in the aggregate and i'm thinking of 3 possible ways: [a] buy another DS14mk4 shelf and continue with 300GB drives - safest way, but most expensive per GB [b] buy another DS14mk4 but use 600GB drives - probably good idea, not so expensive as [a] [c] buy DS2246 with 600GB SAS drives - Probably not a good idea, since drives are different type(in this case 2,5" 10K SAS), but it seems that future will be SAS', it's cheaper per GB and takes less space in rack. As i understand, it is possible to use different drive types in the single aggregate(allthough not recommended), but probably will have some impact on performance. Right now my first choice would be [b] followed by [a]. If anyone would share his/her thoughts on the matter I would be most grateful. Thanks, Joosep

4 5

One large ~40Tb 8 x DS4243 aggr too unbalanced for 3270 ?
by Fletcher Cocquyt 03 Nov '11

03 Nov '11

Fellow toasters, we are trading up some old trays for new DS4243 trays and we are trying to decide if we allocate all 8 of our DS4243 trays to one ~40Tb aggregate (we plan to run ONTAP 8.1 for data motion) assigned to one of the cluster's heads will the advantage of all those spindles in one aggr be killed by the head being overloaded? In which case would we be better served by 2 x 4 DS4243 AGGRs - one assigned to each 3270 head? We also have 7 DS14-MK4 shelves to help balance out the workloads All other things equal - I'm inclined to go for the one big 40Tb aggr vs 2 x 20Tb aggrs to reap the biggest IO capacity and performance Currently our CPU weekly average workloads on the two 3270 heads are only 20% and 16% My impression is a single 3270s head should be have enough headroom to push the large aggr to its full IO capacity. But I'd be very interested to hear the advice others who have tested both options and any unforeseen issues with an aggr this large (our previous largest is 16Tb under 7.3.5.1P2) thanks Fletcher.

4 3

unsubscribe
by Bryan West 01 Nov '11

01 Nov '11

unsubscribe

9 9

List administrivia
by Tom Yates 31 Oct '11

31 Oct '11

Regarding out-of-sequence messages: yes, I'm aware that messages are arriving out-of-sequence again. This is caused by people posting from addresses other than those by which they are subscribed. In what I think is fairly standard anti-spam behaviour for 21st Century mailing lists, this one holds (for moderation) posts from apparently-unsubscribed users. For fastest, and therefore sequential, throughput, *please post from the address at which you have subscribed*. Regarding unsubscriptions: the list engine doesn't deal well with "unsubscribe" requests sent (a) to the full list (b) from an address at which you're not subscribed; I'm not convinced this is the engine's fault. If you want to unsubscribe, there is automated assistance in the headers of every single list message, which most decent mailers will present to you. Every subscriber also gets a reminder on the first of every month that outlines several other methods for unsubscribing, and in the limiting case, you can ask me. Regarding the old archives: I'm still working on it. Regarding the choice of domain name: on Wed, 24 Aug 2011, I wrote: > So if anyone feels strongly enough about this to want to arrange some > kind of forum for this discussion, please contact me off-list so we can > put something together without boring all the people that would much > prefer to read about disc shelf FCAL issues. I'll repeat: please, let's > not continue this discussion here. Although some people have kindly registered alternative domain names, discussion has continued and *noone* has approached me as I requested. I remain open to an off-list approach, where I will be happy to explain _inter alia_ why I haven't favoured the alternative-domain-name solution. If some kind of proposal for change gets traction you can all expect to read a "please go here to vote"-type post. Otherwise, I am fed up reading this stuff on-list, and although I accept that there are still some subscribers who have reservations, I also know there's a body of subscribers that agrees with me. So since it's currently on my server, I will presume to lay down the law a little, for which I beg your collective forgiveness. I will unsubscribe anyone who restarts the domain name issue. If you're leaving the list as you do it, I'll ban you from re-subscribing. Please, *shut up* about the issue on-list. -- Tom Yates - http://www.teaparty.net

1 1

Is there a graph somewhere of performance vs raid group size?
by Cotton, Randall 31 Oct '11

31 Oct '11

We're a relatively small shop just getting started with NetApp (1 2020 and 2 2040's all active/active, plus 3 4342's for the 2040's ). Since committing a disk to a raid group via an aggregate is essentially a permanent thing (you can't change your mind and later shrink an aggregate to pull out a disk from a raid group to use with another node), we'd prefer not to put all our (80) disks in aggregates just yet. We might want more in some nodes and less in other nodes as future needs come into clearer focus. In addition, it's clear that we can later easily add in any disks we've held back as needed and use the reallocate command with the -f option to re-optimize the layout to accommodate the added disks efficiently. So it seems a bit short-sighted to configure all 80 of our disks into aggregates among our 6 nodes right from the get-go (minus the requisite hot spares, of course), as our vendor would have us do. But in deciding how small to start out with, we don't want to cripple our performance too much. I've looked long and hard on the net to find some data, any data, on DOT 7.x performance vs raid group size, but have come up empty. I understand that performance should be awful and unacceptable if you have a raid group of size 3. I also understand from anecdotal evidence that performance improvements from higher raid group sizes are apparently are not significant once you get to a raid group size of 16 or so. But what about in between? How does a graph of performance vs raid size look from 3 to, say, 20? Just ballpark data on any type of remotely typical workload would help a lot to start with. Has anyone ever seen or tried to compile this kind of data? Using iometer, perhaps, or any other benchmarking tool? RAID-DP data is preferable, but I'd take RAID-4 data if that's all I can get. Don't really have the time to do testing myself. Thanks Randall Cotton University of Illinois Foundation

7 22

Re: R: 8.1 64 bit upgrades.
by Fred Grieco 23 Oct '11

23 Oct '11

Is this true for any box or rev level? Sent from Yahoo! Mail on Android

3 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