I dont have any solid data on data/stripe/drivesize performance handy, but it is a wise move to not span raid-groups over multiple FCAL controllers. There will be write degredation involved with that that I have seen. With two F760s rebuilding a manually failed drive while doing nothing else, the machine without a stripe split across FCAL cards completed about 25% before the machine that did span FCAL cards for a raid stripe.
mkfile tests from Solaris confirmed what Id heard..and saw in the reconstruct as part of my test.
:-----Original Message----- :From: mds@gbnet.net [mailto:mds@gbnet.net] :Sent: Wednesday, February 23, 2000 5:04 PM :To: toasters@mathworks.com :Subject: Re: Disk drive technology : : :On Wed 23 Feb, 2000, "Bruce Sterling Woodcock" :sirbruce@ix.netcom.com wrote: : :> The article doesn't say, but bigger, faster disk drives :often draw more :> power. Thus, NetApp needs to have shelves that can support them :> first, before they can test them for reliability. There are :a lot of issues :> involving mechanical vibration and so on that have to be :assessed before :> such a drive could be qualified. It may be that this :particular drive is :> not appropriate for certain shelves. : :Well, yeah, so much so obvious. So how soon was that? 8) : :> More spindles is better performance, if you are read-heavy. :If your filer :> seems slow and it's reading constantly but the CPU is still :under 100%, :> more spindles could help. : :So much for conventional wisdom. However, my question was trying to :elicit something a little more, well, complete as a model of :performance. : :I mean FCAL is a loop technology, and filers can come with 1, 2 or 3 :loops. How much does performance differ when using 1 chain as opposed :to 3 balanced chains, using which drives, using what RAID set sizes and :volume mappings? How does performance get affected by the size of the :disks you use? : :See, if none of these things makes any difference to performance I'd :love to know why. If they *do* then I'd love to know how to build :faster filers. : :I'd be happy with an analytical model, or a set of tables taken from :either real lab testing with real filers, or simulator results. As it :stands though, all we have are rules of thumb that sound plausible. : :The same goes for backup performance. There's been so much discussion :on the list about both topics, but I can't honestly hand-on-heart tell :someone how best to set-up their filers. I'd write something if I knew :the answers myself. : :The best I can find is things like: :http://now.netapp.com/NOW/knowledge/contents/FAQ/FAQ_560.shtml : :I've been meaning to brush up on queueing theory so maybe I *will* try :to work something up myself on this. I'd just hate to reinvent :the wheel :if someone's done it already. I also don't know anything about the :buffers in the filer, on FCAL interfaces, the network interfaces, the :precise use of the WAFL, etc.. So my model might be under-informed. : :Here's a thought to mull over: if you have 20 18 gig drives on 2 loops :and 16MB nvram, will you see better or worse performance than :with 40 9GB :drives on 1 loop with 16MB nvram presuming your clients are all writing :as fast as they are allowed? Please disregard any "such configs aren't :shipped" objections as this is an in-principle hypothetical. Please do :consider the effect of RAID sets, and incremental disk-additions over :the lifetime of the filer in question. I picked writing as the task :because I wanted to point out also that there's an impact on the DOT :algorithms, based on the spindles, the RAID set sizes, and maybe the :chains too. : :I don't know the answer, but I'd like to. Without such models we all :have to purchase filers somewhat in the dark, and either pray that :we got it right, or expend more time than we could in evaluating our :purchases for suitability. : :One question - is anyone else interested in this or am I just shooting :my mouth off needlessly? : :>-- End of excerpt from "Bruce Sterling Woodcock" : :-- :-Mark ... an Englishman in London ... :