toasters

toasters@lists.teaparty.net

13520 discussions

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

8.1 64 bit upgrades.
by Jeff Cleverley 22 Oct '11

22 Oct '11

Greetings, I've starting playing around with the 8.1 RC1 release. I want to upgrade some aggregates from 32 bit to 64 bit. From what I can tell, the only way to do this is to add additional disks to an existing aggregate. Is that correct? I've got one filer with limited disks and don't want to add 1 additional disk to a raid group. I don't want to do all the associated reallocates to smooth out the data allocation. Thanks, Jeff -- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611

6 9

TOE fun?
by Mark Flint 21 Oct '11

21 Oct '11

Hi all, I recently upgraded a V3140 to 8.0.2P1, and all went well apparently. I'n now seeing strange NFS/CIFS behaviour, where a client will make a connection succesfully, but when the client requests a read, the filer FIN ACK's instantly, for no reason I can work out. Got a call open with netapp, but they seem a little fazed by it as well. Anyone seen something similar and can point me? It does seem like it's a TOE problem, but I have TOE turned off on the NIC's, but am wondering if ONTAP is doing something behind the scenes maybe? Thanks, ~Mark mf1(a)sanger.ac.uk -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

1 0

head swap in a fas2050a in a nfs only environment
by Luca Domenella 13 Oct '11

13 Oct '11

Hi guys, i have 2 fas2050a used only with NFS protocol. I need to reinstall one from scratch and snapmirror the data in it. After that I want to swap (one by one) the heads from the other fas2050a in order to dont change the support contract from this storage. Do you see any issue in performing the head swap ? Best regards, Luca Domenella T: +39 0698962316 E: <mailto:luca.domenella@bwinparty.com> luca.domenella(a)bwinparty.com bwin Italia Via Adolfo Ravà, 124 00142 Roma (RM) <http://www.bwinparty.com/> www.bwinparty.com This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk.

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